Hi,

Learnt about this project a while ago, and thought it might be of interest to SAM owners:

http://www.linuxjournal.com/article/7542

The idea is that you can use Python to write programs that will run on an FPGA. Can't remember off the top of my head whether OS4 has Python support (thought it did), but I know AROS does (which runs on SAM too).

Anyone want to give this MyHDL a try to see if it will work on the SAM FPGA? How about some ideas of what you could use it for (super fast Python scripting stuff)?

@HenryCase

Quote:

How about some ideas of what you could use it for (super fast Python scripting stuff)?

Paula, Blitter and Copper Emulation in Hardware for classic games. Someone mentioned thats too small for a whole classic Amiga Emulation like Minimig.

I think we need this because e-uae isn't a satisfactoriness solution for classic games.

Last edited by fingus on 25-Mar-2009 at 11:10 PM.

_________________
I´m back in 2023 on Classic Amiga with my A1200/Blizzard1230IB@50Mhz, 32MB RAM, AmigaOS3.2 and ROMs, Indivision AGA MK3, Author of Amiga-Flipclock (OS4)

@fingus
I agree, FPGA could be useful for Paula, Blitter, Copper emulation, but I was referring to the Python scripting-based MyHDL in terms of something an average Amiga user might be able to write something with.

My knowledge of Python is pretty small, so I'm open to other sugggestions you may have.

@HenryCase

Quote:

HenryCase wrote: @fingus I agree, FPGA could be useful for Paula, Blitter, Copper emulation, but I was referring to the Python scripting-based MyHDL in terms of something an average Amiga user might be able to write something with. My knowledge of Python is pretty small, so I'm open to other sugggestions you may have.

The problem with the FPGA on the SAM is that it isn't connected to the video hookup so it can't run chipset features. It's a rather small FPGA, also.

@Samurai_Crow

Quote:

Samurai_Crow wrote: @HenryCase Quote: HenryCase wrote: @fingus I agree, FPGA could be useful for Paula, Blitter, Copper emulation, but I was referring to the Python scripting-based MyHDL in terms of something an average Amiga user might be able to write something with. My knowledge of Python is pretty small, so I'm open to other sugggestions you may have. The problem with the FPGA on the SAM is that it isn't connected to the video hookup so it can't run chipset features. It's a rather small FPGA, also.

Can it run useful Python scripts via MyHDL? That's the question I'm trying to establish an answer to.

Last edited by HenryCase on 26-Mar-2009 at 12:58 AM.
Last edited by HenryCase on 26-Mar-2009 at 12:57 AM.

@HenryCase

Some sam rev c don't have the FPGA socket (like mine) !!!!!!!

_________________
BTW, what you have done for the amiga today ????

-A1200+Mediator+VooDoo3+060/50+96mo+SCSI-KIT
-SAM440EP-667mhz-on MapowerKC3000+AOS4.1

Amiga Docs Disks Preservation Project

@Mrodfr

I'm sorry for you because the FPGA would be a really nice feature to use.

Does anyone know details about the FPGA of the Sam440 ? How it can be accessed ?

I also want to know who has started to play with it. You can answer here or email me in PM.

As a point of interest, it should be noted that I think my Sam 600Mhz does have the interface.

I'm not certain that the Sam doesn't need the FPGA itself, though, so reprogramming it would lose Sam functionality. You'll need to check with Acube before even thinking of programming it...

Edit: I'd love to hack around with it though. Imagine MAME, where for instance, you could put one of the Z80 audio processors (very common, like in a NeoGeo) into the FPGA. :)

Last edited by Spirantho on 26-Mar-2009 at 07:56 AM.

@HenryCase

(I do ASIC design at work, have mostly done back-end layout and place/route and verification tasks, more recently am working on front-end RTL design using verilog related to microcontroller based ASICs.)

Looks like you still need a verilog or vhdl flow for synthesis, converting the MyHDL Python into one of those other two languages before you can get your python design into an FPGA. It's not a direct thing where your write pyton and MyHDL knows how t oput that into your FPGA directly. You'll still need synthesis, place and route tools, and whatever tools to program the chip. I asked Acube once but didnt' get a response about the FPGA.

I suspect the MyHDL thing is for system design when someone knows python and doesn't want to (learn to) write RTL in either verilog or VHDL directly. Do the human part of things in the more comfortable Python language, then use the verilog/VHDL conversion path to get into the automated tools on the way to FPGA or ASIC silicon.

Which FPGA is this? (do you get synethsis and place/route tools from Xilinx or from Actel or from Altera or???) What capacity is it (how big of a design will fit?)

How is the FPGA programmed? From an EEPROM? From a PROM? From a flash? from teh CPU via SPI or some GPIOs somewhere? Parallel or serial? Is this changable from the Sam via software, or must an in-system-programmable cable be used from a PC? (after it's programmed, different configs in the memory may be swappable on the fly, but they may have to be programmed there first)

Then, what is the FPGA conneted to? Can we access it via local bus? via PCI? Does it conenct to any other chips on board, such as to mux Radeon output with Minimig video to the VGA connector? Audio muxing connections? Or is it "just there" connected to a header but not to anything else ni the system? (how do we connect to that header to talk to the FPGA if no other comunication path is available?)

ALso look up icarus, a free/open-source verilog simulator. Probably would be smart to simulate some verilog anyway after conversion from python, just to double-check their python translation math. And again after synthesis to gates and place/route. At work we do at least three levels of simulations. First on RTL (the human verilog/VHDL design), second on pre-route gates (after synthesis but before place/route), and third is after place/route.

RTL: Register Transfer Language - this is the human code design, compare that to programming in C, C++, Java, whatever.

synthesis: this is sorta-kindof like a step in compiling C/C++/Java to an intermediatemachine level. This gives you a netlist made out of interters, and gates, or gates, buffers, flip-flops, etc. all wired together. It may be specific to a family of FPGA chips or specific to an ASIC fab process due to whatever cell library was chosen. (xilinx Virtex 5 likely has a different cell library than Spartan3 for example, as cell libraries have some timing info) This may also add testing features into the design, such as ATPG (google it), JTAG scan flops, maybe do some preliminary enhancements to help meet timing (add large buffers to wide fanout nets, one signal which has lots of destinations such as the clock tree or memory address/data bus with lots of memory cells to connect to), etc.

place/route: this process takes your synthesized gate netlist and fits it into your specific FPGA chip or ASIC layout, placing cells in particular locations, figuring out the wiring and delays in between, may add buffers to long wires to help with propogation delays more secifically to the layout as it sees where different cells are ending up located respective to what drives them and what listens to them.

Last edited by billt on 26-Mar-2009 at 01:23 PM.

_________________
All glory to the Hypnotoad!

@billt

Someone mentioned the Sam FPGA is small.

If you have access to the onboard FPGA via local bus or PCI, consider that even if it only has a header for the other FPGA pins and does nto otherwise connect to the system itself, you could use it as a bridge to another board with a larger FPGA and more connectors should that be needed to something more useful.

_________________
All glory to the Hypnotoad!

I wonder if it would be possible to use the FPGA for accelerating video playback? The 533mhz Sam model seems slightly too slow for xvid/divx playback so that would certainly help if possible.

@billt

I've got a response to my questiosn for Acube, apparently I somehow did not receive their first reply a while ago. They gave permission for me to share here.

What FPGA is this, model/capacity?
Quote:

The FPGA is a Lattice XP6C, 5.8K LUTs http://www.latticesemi.com/products/fpga/xp/index.cfm?source=topnav&jsessionid=ba3039913047l$3F$7Bw

What all is it connected to? CPU local bus? PCI? Header type/pins? Any other connections to chips that might be used to mux those chips with FPGA IPs? Memories? etc...
Quote:

It's connected to the CPU local bus, 16 bit data, 21 bit address, up to 66 Mhz. On the other side, there is an 80 pins expansion IO connector to the FPGA.

Will the ITX and Flex boards both have the same FPGA and same connections to the system?
Quote:

Yes, same connection, same FPGA and same phisical IO connector

How can these FPGAs be configured? Are they hardwired to a configuration memory, can they be reconfigured on the fly or only after configuration flash/reboot?
Quote:

The device is a non-volatile FPGA, it needs to be programmed only once. To programm the FPGA you can use the JTAG connector onboard, or use the JTAG pins which are present on the expansion IO connector.

Are these FPGAs partially reconfigurable on the fly? Such as if it was used for codecs, could codecs be reloaded and changed out to different codecs to the chip at will while the system is running as an example? So one could watch a DVD then switch to WMA playback, then to mp3, etc. without reboots?
Quote:

Yes, it should be possible to reprogramm the FPGA on the fly, but there is need to prevent access to the FPGA while it's reprogrammed

_________________
All glory to the Hypnotoad!

@billt

Quote:

Quote: Yes, it should be possible to reprogramm the FPGA on the fly,...

Cool!

But I hear it is used for some tasks on the Sam. What are those?

I have only dealt with RAM-based FPGAs and I must say it seems much simpler (and faster) to reload a RAM-based FPGA than a flash-based one.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@billt

That’s good news; maybe DVD playback is possible after all.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Deniil715

Quote:

But I hear it is used for some tasks on the Sam. What are those?

Ask Acube and post here. But as they say the FPGA connects to the CPU local bus and connects to the header, I'm not sure what use that is to make the motherboard itself function at all.

Quote:

I have only dealt with RAM-based FPGAs and I must say it seems much simpler (and faster) to reload a RAM-based FPGA than a flash-based one.

Read up on the Lattice site about the chip. Sounds like the FPGA has SRAM based configuration, but the programmed design is held in on-chip flash, which is copied to the SRAM configuration memories when powered on. So I think it's still a RAM-based FPGA, just does not have an external configurator to hold the bitstream. May not just move the flash configurator die into the same package, might be, however they do it sounds like similar result.

_________________
All glory to the Hypnotoad!

Some info about changing the FPGA circuit on the fly while the system continues running:
http://www.latticesemi.com/dynamic/view_document.cfm?document_id=21638

Seems you need to rewrite the in-FPGA flash and then trigger a reconfig to in-FPGA SRAM for things such as changing which hardware A/V codec is active, or changing from DVD codec to loading up MiniMig as examples. I know flash has improved in recent years, but you'd be rewriting the flash pretty often, an act which does have some aging effect on the flash memory transistors. I was hoping we'd be able to update the in-FPGA SRAM more directly to change what it's doing. Other FPGAs are only SRAM and have no in-chip FLASH, and allow this.

But it sounds like one needs to use the FPGA JTAG port to change the FPGA anyway, Acube mentioned that on the header or the jtag "onboard" can eb used. I'm not sure if the "onboard" JTAG means the CPU has access to update the FPGA flash via software, or if some JTAG cable from a PC is needed either way. If SAM does not have direct CPU access to teh "onboard" jtag port, one might define part of the FPGA to be a software controllable JTAG controller and use some generic FPGA IO pins to the header as JTAG output port, and have a loopback board to connect that to the "true" configuration update jtag port. I'd hope that unnecessary though, as it would consume part of the FPGA capacity.

Hmmm, looking at the Sam440 manual, there's a jtag header next to the FPGA, separate from the FPGA IOs header. I'm guessing no CPU/software access to that. But an alternative to consuming FPGA capacity with a JTAG controller, there's the CPU GPIO connector nearby as well, there's probably enough of those GPIO to connect to the FPGA JTAG, and have software control to talk to it that way for reprogramming what the FPGA does. Any method of reprogramming the FPGA needs to have a store of FPGA configuration files to keep writing into the FPGA, not so hard, but we'd have to look up the signal controls for putting that file over JTAG into the FPGA correctly. And it'd need a small PCB to connect the cpu GPIOs to the JTAG, and write software that controls the GPIOs as needed by the FPGA JTAG programming process.

Also need to spend some time reading
http://www.latticesemi.com/dynamic/view_document.cfm?document_id=9403
and other related docs at
http://www.latticesemi.com/dynamic/index.cfm?fuseaction=view_documents&document_type=31&sloc=01-01-00-60&source=sidebar&jsessionid=ba30e5d0bc40$12Z$92$

Last edited by billt on 26-Mar-2009 at 09:57 PM.

_________________
All glory to the Hypnotoad!