Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
> Hi > Does anyone have some advice for the fastest say to get many MBytes of > data from a Spartan3 fifo to the hard disk of a PC via usb. I assume > that it is a combination of the best USB interface next to the FPGA and > perhaps a USB chipset in the PC that can do some very clever DMA. > I don't want to mess with custom RAID stuff I just want to dump it to a > standard hard disk & controller. > Any pointers appreciated. > Colin Colin, I think a PCI interface capable of bus mastering will still be faster than a USB2.0 interface. The PCI performance is slightly un-deterministic as it depends what else is on your bus, but from what I've read here over the years I think 80MB/s is a reasonable expectation. I half remember reading that although USB 2.0 gives you 460(?) Mb/s that this doesn't directly translate ~ 460/8 MB/s of data through-put (ie 60MB/s). Nial. ------------------------------------------------------------- Nial Stewart Developments Ltd FPGA and High Speed Digital Design www.nialstewartdevelopments.co.ukArticle: 91726
Thanks to you all, ciaoArticle: 91727
air_bits@yahoo.com writes: > Anybody else have pet ideas, suggestions, or wish-list items that > a C based HLL/HDL tool should handle? > I had a quick play the other day and I noticed that the counter example generates it's own set of lookup-tables for the increment logic, creating an enormous VHDL file. I imagine the code generator could be simplified somewhat to take advantage of modern synthesis... writing a process with x:=x+1 in! My personal wishes for it would be a) you can "simulate" the code with a suitable wrapper using a normal C-compiler b) you can explicitly parallelise stuff within a given function c) some form of communication is provided between processes, that also simulates in boggo-C. Something like Occam channels or FSL ports would be my preference Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.trw.com/conektArticle: 91728
Ray Andraka <ray@andraka.com> writes: <snip> > It generally > does take someone seasoned to turn out an FPGA design that uses the > resources somewhat efficiently, that is going to be reliable, and that > isn't going to spend a large part of the time to market in some lab > chasing down countless naive design errors. My comments are not aimed at Ray in particular, but I thought I would just note that that's true of embedded software also. Surely the point is that doing things efficiently and reliably (especially in resource limited environments) is Not Easy and you have to have competent (or better, depending on the project!) people doing it. They also need good tools to do the job. Personally I'd love to get away from writing low-level VHDL for *some* of the things I do, but I wouldn't fancy writing an SDRAM controller in a C-like HDL either. There's a phrase involving hammers and nails that springs to mind... Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.trw.com/conektArticle: 91729
On 11 Nov 2005 01:07:38 -0800, "colin" <colin_toogood@yahoo.com> wrote: >Hi > >Does anyone have some advice for the fastest say to get many MBytes of >data from a Spartan3 fifo to the hard disk of a PC via usb. I assume >that it is a combination of the best USB interface next to the FPGA and >perhaps a USB chipset in the PC that can do some very clever DMA. >I don't want to mess with custom RAID stuff I just want to dump it to a >standard hard disk & controller. > >Any pointers appreciated. > >Colin Something else you may want to think about is a dual-port interface to an extarnal USB2 HD, i.e. FPGA to IDE, and IDE to USB2 using one of the standard chips available for this. This would have the advantage of more deterministic timing and probably higher throughput.Article: 91730
"Adam Megacz" <megacz@cs.berkeley.edu> wrote in message news:x1fyq6mx8i.fsf_-_@nowhere.com... > > "IP Core" is often [mis]used even when the writer does not mean to > exclude public domain or open source works. For this reason, the term > "gateware" is preferred unless you intend to deliberately exclude > noncommercial creations. > > http://en.wikipedia.org/wiki/Gateware > Hi Adam, Did you just make up that word? A quick search of C.A.F. in Google groups gave me a grand total of 4 hits. I wouldn't call that 'preferred'! I also note that the Wikipedia discussion page is somewhat negative on this usage, saying it's probably a candidate for deletion. The most non-C.A.F. Google hits for it seem to be for software in network gateways. I could find no mention of it anywhere on opencores.org. Best, Syms.Article: 91731
I'll add to that and say that the USB controller in the PC is probably sitting on a PCI bus or at least affected by the traffic on it. Also worth saying fastest USB is 480 MBit/s excluding overheads and 32bit/33MHz PCI is 1056 MBit/s excluding overheads. John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board. http://www.enterpoint.co.uk "Nial Stewart" <nial@nialstewartdevelopments.co.uk> wrote in message news:43746c57$0$355$da0feed9@news.zen.co.uk... >> Hi >> Does anyone have some advice for the fastest say to get many MBytes of >> data from a Spartan3 fifo to the hard disk of a PC via usb. I assume >> that it is a combination of the best USB interface next to the FPGA and >> perhaps a USB chipset in the PC that can do some very clever DMA. >> I don't want to mess with custom RAID stuff I just want to dump it to a >> standard hard disk & controller. >> Any pointers appreciated. >> Colin > > > Colin, > > I think a PCI interface capable of bus mastering will still be faster than > a USB2.0 interface. > > The PCI performance is slightly un-deterministic as it depends what else > is > on your bus, but from what I've read here over the years I think 80MB/s is > a reasonable expectation. > > I half remember reading that although USB 2.0 gives you 460(?) Mb/s that > this doesn't directly translate ~ 460/8 MB/s of data through-put (ie > 60MB/s). > > > Nial. > > > ------------------------------------------------------------- > Nial Stewart Developments Ltd > FPGA and High Speed Digital Design > www.nialstewartdevelopments.co.uk >Article: 91732
For all that are interested we have some free lunchtime seminars, and following optional lab, based on using and building up a MicroBlaze microprocessor design. Some initial basic details here http://www.enterpoint.co.uk/seminar/seminar.html. There are 2 dates confirmed (Malvern and Warwick) so far in the UK and probably 2 more TBA. If someone has a good suggestion for a location elsewhere in europe let me know and I will see if it can be added to the schedule. John Adair Enterpoint Ltd. - Home of Raggedstone1. The Cheap Spartan3 PCI Development Board. http://www.enterpoint.co.ukArticle: 91733
"Ray Andraka" <ray@andraka.com> wrote in message news:F0Scf.2230$Mi5.2093@dukeread07... > This is true provided you access every single row, > well at least every row you have data in, within > the refresh time. This can be used to advantage in video frame buffers, > for example as long as the frame time does not exceed the refresh time. > So yes, it can be useful. It doesn't save a lot of memory bandwidth or > time, but it can substantially simplify the DRAM controller in your > design. Good point. The BBC micro interleaved access with the 6845 CRTC, and the regular sequential video accesses did the refresh.Article: 91734
colin a écrit : > Hi > > Does anyone have some advice for the fastest say to get many MBytes of > data from a Spartan3 fifo to the hard disk of a PC via usb. I assume > that it is a combination of the best USB interface next to the FPGA and > perhaps a USB chipset in the PC that can do some very clever DMA. > I don't want to mess with custom RAID stuff I just want to dump it to a > standard hard disk & controller. My two cents : You might instead consider implementing a simple IDE hardware interface, the protocol is quite straighforward if you stick to PIO mode (no DMA, however you can reach almost 15 Mbytes/sec, which is close from what you usuallay with an USB drive). The amount of effort needed to implement the IDE interface might actually be lower than trying to interface with an external USB bridge Here is a link to a open-source IDE controller IP core http://www.opencores.org/projects.cgi/web/ata/overview I don't know how efficient it is (we rolled our own). Hope it can help ... Steven > > Any pointers appreciated. > > Colin >Article: 91735
Definitely use a crossover for this kind of work, direct to your computer, and no DHCP on either side - that way, there's only one place your packet can go, so you on't have to worry about your switch/router doing any funny stuff with it.Article: 91736
I am using the exact same RAM with Ateras SDRAM controller, which has source with it. Are you doing this just for academic purposes? I would suggest looking at their core, just because I know it works :)Article: 91737
Thaks for your 2 c :) Unfortunately I currently only using combinatorial logic (output0 <=3D input0; output1 <=3D =B41=B4; output3 <=3D '0'; ), no clock yet, and no logic that expects a clock... Code is OK, is implemented the same program on my Spartan 3 fpga, works as expected. I found a 4 line post on the Xilinx state descibing one of the features for a service pack as "(SP2) 7.1i CPLD Hprep6 XC9500/XL/XV CoolRunner XPLA3 - Device (Jedec) does not function properly on the board (Xilinx Answer 21168)", so I'm downloading the SP now, will try that out later... >> "when everything doesn't move, check the clock first..." I like this - I'll use it in the next part of my design :) johannesArticle: 91738
This isn't a specific embedded or FPGA problem, but I'm hoping someone has some advise. Does anyone know of a 6V 12Ahr Sealed Lead Acid Battery that has been able to pass FM's or ATEX short circuit temp. rise test? I designed in a Diamec DM6-12, but when Factory Mutual was testing the short circuit temperature rise of the battery within a few seconds the battery becomes an open circuit and it has only raised 3 degrees C. (There must be some mechanical fuse-able link inside) So they can't actually test an internal cell short circuit fault from the outside of the battery. FM doesn't want to cut open the battery and actually test the internal cells for heath risks, which I understand. If you have any ideas on a new battery, that would help me out a lot. Thanks EricArticle: 91739
Thanks guys. But Andy, what is there to do when there is no F'in data sheet to read (in scared )? The part is a company internal ASIC on its first spin and actually that spec is not a problem right now . I KNOW that there is a delay associated with respect to when the external part presents valid data after a rising edge of the clock it sees. By the way, the clock that all my synchronous logic is being driven from is 2x the clock the external part sees. The whole state machine is rising edge driven from that clock. The clock the external device sees is generated in synchronous logic by that clock too. I use the derived clock's levels (not edges) internally to see when I need to clock data out and clock data in. Those specs (when data transitions) are different depending on which company part I am writing/reading so it HAS to be flexible. Anyways, I digress.... I can monitor the delay from rising edge of the clock the part sees to when data is valid. I am looking at it on an o-scope. No problem. All setup times are WELL within margin. The problem occurs somewhere in the FPGA. If I could sample the data at the external pins I am looking at on the o-scope, then I would read back correctly ALL of the time. The FPGA works fine when we are NOT using the extender board...the part is much closer to the FPGA. When using the extension, the read back data is incorrect. Again, it looks fine on the o-scope in BOTH cases. In a simplified delay equation of: total delay = delay from part to FPGA pin + delay from FPGA pin to internal logic module, I need to use the delay from FPGA pin to internal logic module as my variable. That is the value I need to tweak. This is hard to make sense of in a forum without typing a document! Thanks.Article: 91740
We recently implemented a design that moved to a PC using USB 2.0 We used a Spartan3 coupled to a Cypress FX2 part and were able to achieve 30MB/sec transfer rates. It took careful driver development on the PC to get the performance level up high enough. It was a fun project, but the Windows driver development took a lot longer than expected - it was tricky to get the performance up to where we needed it. John ProvidenzaArticle: 91741
Martin Thompson wrote:
> Personally I'd love to get
> away from writing low-level VHDL for *some* of the things I do, but I
> wouldn't fancy writing an SDRAM controller in a C-like HDL either.
There is a middle ground already available
using standard vhdl synthesis that
doesn't cost a dime or a gate or a flop.
I use single process entities
with no signal declarations.
I declare process variables for every
local register and output port.
I use functions to create values
and procedures to collect and name
all repeated command sequences.
I use exactly this template of
three top procedures in every
new design entity:
begin -- process template
if reset = '1' then
init_all_regs; -- no port init required
elsif rising_edge(clock) then
update_process_regs;
end if;
update_output_ports; -- wires ok for reset or clk
end process template;
This style feels somewhat C-like but the
template keeps me in "think hardware" mode.
-- Mike Treseler
Article: 91742Martin Thompson wrote: > I had a quick play the other day and I noticed that the counter > example generates it's own set of lookup-tables for the increment > logic, creating an enormous VHDL file. I imagine the code generator > could be simplified somewhat to take advantage of modern > synthesis... writing a process with x:=x+1 in! I had a similar experience and mind set for a while, but I'm not so sure after spending a few hours hacking on the code to preserve bit vector naming last spring. The VHDL netlist output is called after all the optimizations have been done in FpgaC, and it more or less then attempts to build the same circuit structures in VHDL that it would in XNF. Internally TMCC/FpgaC does not save statements while parsing, it goes straight to building internal netlists for the operations. As a result using FpgaC for a C to VHDL translator is more than a bit of work and would radically interfer with the compiler C to netlist functions. It would effectively require breaking FpgaC into two parts, which would probably be better done by stripping the backend off FpgaC and making a second tool for a C to VHDL translator that would preserve statement level syntax. Since the long term goal is to produce good XNF/EDIF netlists that are tightly integrated to a set of RPM's and cores for reconfigurable computing, it has not been clear if VHDL output is the best way to get there, or a diversion. > > My personal wishes for it would be > > a) you can "simulate" the code with a suitable wrapper using a normal > C-compiler That is already the goal for FpgaC. I've already done some of this as I've hacked the original TMCC work. Implementing the rest of the C native types, moving the port definitions to pragmas, and starting the move to using bit field syntax is all part of that goal. The current bit field size hack isn't precise C, as FpgaC doesn't have structures. One of the next changes is to introduce structures, unions, and enums into Fpga so that bit fields in a structure will be the same as bit fields in standard C. Adding some pragmas which guide enum, counter, and state machine generation by suggesting one-hot, grey coded, and traditional counter types is somewhere in the long term road map. Typedef also needs to be added, but that will probably happen sooner as we fix the symbol table scoping rules in the next group of changes that will overhall the entire symbol dictionary code. While other C to netlist tools are generally trying to make C an HDL, and are willing to make radical changes to the language departing from std C, I'm looking to target FpgaC as an HLL to netlist tool, less concerned with having it compete directly with VHDL/Verilog. The intent here is to make FpgaC a very good C to netlist tool for reconfigurable computing, which preserves std C execution expectations on a traditional compiler and cpu. Thus, it should always simulate correctly on a cpu, unless you work hard to break it by using some HLL specirfic feature (if any remain), or the word size choice in the netlist target can not be represented in the CPU you are simulating on and there are some word size or endan problems as a result. > b) you can explicitly parallelise stuff within a given function This breaks a). The goal is to do a) in the most parallel way that can be done transparently. Much as multiissue super scalar CPU's do .... IE exploit as much parrelism as exists in the sequential specification. This is actually quite a bit, and frequently much more than a super scalar processor can muster. Currently, every statement block is allowed to become a flattened combinatorial netlist. So a single statement loop, doesn't have much parallism, unless it's a pretty complex statement with a lot of subexpression operations. There we win, as the entire expression can be flattened to a single combinatorial net list. Later to improve this I plan to add loop unrolling guided with a pragma as a space time tradeoff. This doesn't break a), and preserves the ability to use a traditional cpu as an effective simulation environment. > c) some form of communication is provided between processes, that also > simulates in boggo-C. Something like Occam channels or FSL ports > would be my preference In a traditional multiple processor environment, MPI and PVM provide the communications standards that are widely used. The intent is to create some intrinsics that the compiler uses to build mailboxes and FIFO's for IPC needs, and then provide an FpgaC set of libraries and header files that do most of std libc, MPI, PVM and posix-threads. This addition to FpgaC is needed to handle PCI to host communications, as well as inter-FPGA communcations in multiple FPGA platforms. Extending FpgaC in this way, preserves a).Article: 91743
motty wrote:
> By the way, the
> clock that all my synchronous logic is being driven from is 2x the
> clock the external part sees. The whole state machine is rising edge
> driven from that clock. The clock the external device sees is
> generated in synchronous logic by that clock too.
For a synchronous interface to work properly without
a handshake, both ends need to see the clock rising
edge at exactly the same time. The only practical
way to do this for more than an inch or two is
use a zero-delay clock distribution chip and
wire equal length transmission lines from the chip
to the clock input at each end of the interface.
You have to cover both the normal and extended cases somehow.
Or add a handshake.
Or go source synchronous.
Or tune up the clock delay using the fpga PLL.
-Mike Treseler
Article: 91744Mike Treseler wrote: > This style feels somewhat C-like but the > template keeps me in "think hardware" mode. Yep. Then the big difference starts, debugging in "think hardware" mode, or debugging in "think software" mode using source level debuggers with break points, single stepping and variable watching at a high level.Article: 91745
I should add, that Chirag and I coulfd use help in realizing these goals.Article: 91746
Eric wrote: > This isn't a specific embedded or FPGA problem, but I'm hoping someone > has some advise. > > Does anyone know of a 6V 12Ahr Sealed Lead Acid Battery that has been > able to pass FM's or ATEX short circuit temp. rise test? > > I designed in a Diamec DM6-12, but when Factory Mutual was testing the > short circuit temperature rise of the battery within a few seconds the > battery becomes an open circuit and it has only raised 3 degrees C. > (There must be some mechanical fuse-able link inside) So they can't > actually test an internal cell short circuit fault from the outside of > the battery. > > FM doesn't want to cut open the battery and actually test the internal > cells for heath risks, which I understand. > > If you have any ideas on a new battery, that would help me out a lot. > > Thanks > > Eric > Ask this question on sci.electronics.design -- it'll be seen by way more analog folks that way. I, alas, do not approach that level of expertise with batteries. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 91747
Jim Granville wrote: > It would requires more of the designer, but what about a pragma like > the ASM one, in many C's ? - it would accept VHDL (or verilog), and > pass on to the downstream tools. > The advantage is it would understand the variable names, and scopes, of > the other source ( much like in line asm does now ? ). > If a LOT of HDL code was needed, then separate code modules would be > better. That's a hard one, and I've considered it several times, then backed off to using perl post processing of the XNF. My current feeling is that it's probably wrong to do this in FpgaC, except maybe for the XNF outputs. The real problem here is that any feature such as an ASM, probably needs to be reasonably respresentable in any of the output forms for the net list. As we move from XNF to EDIF netlists, it gets even more difficult, because small changes need to be reflected into several different portions of the EDIF output, where at least XNF is pretty linear in that respect, just as machine language statements would be into an assembler. To be truthful, to make ASM work, the logic optimizations would have to be turned off, and the resulting netlist would get pretty bloated. There would also have to be some specific hacks to make the internal symbols visible, since there are not architecturally specified resources like machine registers that ASM would target in a traditional ISA machine. The last arguement against it, is that it breaks the reason for making FpgaC as close to std C on a CPU/Memory, as the code is no longer directly testable on a traditional programming platform. So from this perspective it's better to push things that don't directly fit the std C model, into another HDL (Celoxica-C, VHDL, Verilog) and debug those parts separately using hardware simulators and hardware debuggers, and protect the ability to debug the rest of the C HLL system with stubs for the hardware interfaces and use more efficient HLL debugging tools. It would not suprise me to see one or more people fork FpgaC to become an HDL for specific projects, or even take TMCC which was intended as an HDL and similarly extend it. If it makes sense at some point, maybe the FpgaC team will go ahead and do it, creating a second FpgaC_HDL tool chain. There is likely to always be this dual headed monster of is FpgaC an HLL for reconfigurable computing, or an HDL for hardware design on FPGA's? My perspective is that doing the HDL side right requires a lot of optimizations for target FPGA's that are not particularly general. I believe it is possible to do FpgaC for reconfigurable computing uses that is a lot more general, less tied to target FPGAs, and this is the use that is not well supported by other HLL/HDL tools, paticularly when you consider test and debugging and the relatively horrible mess of using gate/timing simulators to debug HLL algorithms and multiple threaded applications with communications.Article: 91748
Can you get some testing documentation from the battery company that certifies that it meets the requirements? I know that FM likes to do their own testing, but they may be willing to accept data that proves that it meets their requirments, especially if fault testing is hampered by a safety feature of the device and to bypass it would be dangerous.Article: 91749
Eric wrote: > Does anyone know of a 6V 12Ahr Sealed Lead Acid Battery that has been > able to pass FM's or ATEX short circuit temp. rise test? Umm... did we try google "factory mutual sla battery"? Multiplier Industries Corp. - http://www.multiplier.com/ Manufactures rechargeable Ni-Cd, Ni-MH, Li-Ion and Factory Mutual approved batteries custom packaged for the OEM. But there are plenty of SLAs available, also try Rocket (Global & Yuasa) and Casil (Chee Yuen) as I know these specific brands, among others, are used in FM-listed fire panels.
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z