Assembled Minimig v1.1, larger FPGA (BGA-package)

[ThomasML]

jkonstan wrote:
Did you rebuild the MiniMIG Xilinx ISE Project with the new Spartan3E part/BGA package to make sure that new pin out would route (i.e. is the resulting pinout from Xilinx ISE floor planner)?

No, I'm pretty sure it'll route well, but I'm about to install ISE and compile it now.  Will let you know if there's any suggested changes from ISE.

The FPGA I've chosen has 1200k gates, tho, so it's a bit bigger than the one on the minimig today.  It's also large enough to fit a 68k inside the fpga.

Also, please see Xilinx Spartan3/3E APP notes on BGA 4/6layer PCB and on SSO (Simultaneous switched outputs).

http://www.xilinx.com/xlnx/xweb/xil_publications_display.jsp?iLanguageID=1&category=Publications/FPGA+Device+Families/Spartan-3E/Application+Notes
Check Xilinx XAPP689.pdf
Check Xilinx Xapp489.pdf

Yeah, I'll make sure to read those when I'm done with the schematics and starting on the pcb-layout.  I've been altering a few things more than once lately, as I've been talking to Dennis on email and getting a few ideas here and there :-)

--
Thomas

[ThomasML]

AJCopland wrote:
lol well i can't comment on the technical side of it but it looks like all the main blocks I can identify are there. You'll have 10 user_io pins left. All 16 of the CPU address and data lines, likewise for the ram.

Actually, there's 10 user input-pins left, and 38 user input/output-pins left.  So, a total of 48 pins left for fun and expansion.

--
Thomas

[jkonstan]

Thomas,

Please connect the MC68SEC000 Berr* pin12 to one of those  FPGA pins.

 :-)

[ThomasML]

jkonstan wrote:
Thomas,

Please connect the MC68SEC000 Berr* pin12 to one of those  FPGA pins.

That's marked as VCC in the schematics I have.  Is that an error?  Should it be on one of the Input (or Input/Output) pins from the FPGA?

--
Thomas

[jkonstan]

Thomas,

Please see this Open Circuits MiniMIG link where I explain why Berr* would be a nice to add back into the design.

http://www.opencircuits.com/Minimig_68K_CPU_BERR%2A_Support

  :-)

[ThomasML]

jkonstan wrote:
Thomas,
Please see this Open Circuits MiniMIG link where I explain why Berr* would be a nice to add back into the design.

Ok, I'll add map it, it's not like we're running out of pins or anything :-)

--
Thomas

[Tron2k2]

Hi all

This is so cool!  This very much reminds me of why I got into the Amiga to begin with :-)

Anyway, since the new FPGA has so many gates, are there enough for, say, an 020 or even 030 CPU in there?  I mean, if you're making a whole new 'classic' Amiga then would it be too complex to make it an accelerated one?  Even WB1.3 runs fine on an 030.  I'll buy one regardless, but I'm just blue skying here.  Is a faster CPU possible?  Or do you just physically install one instead?

[AJCopland]

Whilst 020 or 030 would be nice for a later revision I think this particular v1.1 revision is just to give us more pins to do things with from an expansion point of view. Though it is ThomasML whos doing the work on this version so he'd have a better idea.

Also adding an 020 or 030 has been discussed and seems like a major redesign of the board for a seemingly large number of reasons. Everything from voltages through clock speeds via board trace layouts etc and a bunch more stuff I didn't understand ;-)

Andy

[JimS]

Tron2k2 wrote:

Anyway, since the new FPGA has so many gates, are there enough for, say, an 020 or even 030 CPU in there?  

Someone's looking into that....  I believe the open-source 680x0 core has some problems. Another interesting idea- put the PIC controller in the FPGA. That would save a chip... but then you'd have to add a flash ram to load the FPGA.

[freqmax]

While doing BGA, a switch to DRAM would also make ram cheaper and larger.

With DRAM use + HDL cpu an ordinary pre-assembled 200 USD board can be used..

@JimS:
Putting the MCU (pic18) inside the FPGA poses an interesting chicken-and-egg problem. It will make upgrading the FPGA flash  more cumbersome. And soldered EEPROMs have a limited number of write cycles.
The EEPROM loads the FPGA. And the FPGA can then read the flashcard. But it can't reload itself.

[ThomasML]

freqmax wrote:
While doing BGA, a switch to DRAM would also make ram cheaper and larger.
With DRAM use + HDL cpu an ordinary pre-assembled 200 USD board can be used..

What kind of pre-assembled board are you talking about now?  You mean we could use any of the starter kits instead of doing a custom board?  Or, are you thinking that one could use the starter kits if one doesn't want to buy a custom board?

I also found flaws in my fpga pinout, I was missing some pins, so I've floorplanned it inside ISE now.  Will publish the new suggested floorplan tomorrow.

--
Thomas

[freqmax]

Yes, one could use pre-assembled ready to use developer boards. The only major obstacles is the physical CPU & Static-RAM.

VGA, Keyboard, means to load software, user i/o etc.. Is already there. I found XC3S1200 for 300 USD at digilentinc and XC3S1000 for 200 USD at xess.

This was my initial idea of an A500 implementation in FPGA. No need for special purpose boards.

[ThomasML]

freqmax wrote:
Yes, one could use pre-assembled ready to use developer boards. The only major obstacles is the physical CPU & Static-RAM.

They're larger and contain stuff you probably don't need tho, but it would serve a purpose of course.  In the end I think one would want custom boards tho, to be able to make the device smaller or just have all the cool stuff developed along the way, on one board.

But right now, we don't have anything besides a few schematics and nothing for mainstream to play with.  And the boards you're talking about is a bit more pricey than most people would like, I think.  (I'm not most people, I've already got digilents V2Pro-board  :-D  ).

So, what do you suggest we do?   I don't need to continue this work if it's not needed (don't take this the wrong way).   What one could do, is to make the board like it's now, with the extra user io-pins and everything, and continue developing the soft 68k and adding dram as an expansion.  Some day down the line one would maybe end up with a working solution, but right now we only have the proven minimig-design that works.  And we all know there's other work to be done to it, besides just the cpu and ram.

Any thoughts? :-)

--
Thomas

[Fantoma]

If I had to base all work on one fpga all-in-one board I think Enterpoint's Darnaw1 would be suitable.  Its small, it can be used on 2 layer boards with 110 I/Os and on a 4 layer board 219, it has a 1200k gate Xilinx fpga and some RAM.  No unwanted extras really.  Initially you would have to make a 'motherboard' to plug it into with CPU, SRAM and PIC and regular ports but over time you can cut it down to just the ports, the rest is on the fpga.  

1.2M gates should be well and truly enough space for whatever we can come up with - The main issue is price.

[freqmax]

@ThomasML:
They may be large and contain stuff you don't need. But they are working out-of-the-box for those that lack soldering skills. But have programming skills.
I think a custom board is excellent, but one doesn't have to require that everyone must have one to even get started.

I suggest we move to Dynamic RAM and make the HDL code compatible with the soft m68k code with high priority (Bonus is at least 32M ram!).

@Fantoma:
Darnaw1 have onboard 16 MByte DRAM, CPU can be simulated with soft m68k core and MCU (pic18) can be coded as HDL. Though some upgrade issues may arise.

@all:
Having all the critical stuff in one premade board eliminates many EMI issues aswell.

The Webpack have builtin DDR controller and opencores.org should have support for anything older. Then adding 68k core. One will have to initially put in checks and debug the code to make it start I presume.

It's also possible to use some of the blockram in Xilinx FPGA to debug the m68k core first. And then turn to debugging Dynamic ram. The distributed ram +
blockram in XC3S1600E is 109 kByte. This would allow using the parts of kickstart as test code. And then go ahead with Dynamic RAM support on a plain developer board.

Also keep in mind that Xilinx Webpack supports upto XC3S1500 and XC3S1600E. After that you have to pay for the P&R tool.

The real bottom line with this is that we will get many more developers on Minimig. So that other issues will be resolved faster. So any coding towards DRAM + soft CPU will help other issues implicitly.

[ThomasML]

Ok, new layout, this time I've used ISEs floorplanning tool, and I've also done synthesis and bitfile generation.