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
Giuseppe Marullo wrote: > Jan, Frank, Tim, Nico and Andy, > many thanks for your answer. I would like to stick with Verilog, at the > moment I am trying with the following code: Looks good, it uses the same idea I've used, sampling in the middle of a bit after the start bit detection. This is not perfect, better receivers use e.g. 8 times oversampling and a majority algorithm, but should work, if your signal is not too noisy. But you should latch the rx input, to avoid metastability problems. I don't know how to do this in Verilog, something like declare another reg with the name "rx", rename the raw input signal and copy it on rising clock edge to "rx". -- Frank Buss, http://www.frank-buss.de electronics and more: http://www.youtube.com/user/frankbussArticle: 153726
Frank Buss <fb@frank-buss.de> wrote: (snip) > But you should latch the rx input, to avoid metastability problems. I > don't know how to do this in Verilog, something like declare another reg > with the name "rx", rename the raw input signal and copy it on rising > clock edge to "rx". Can you explain the problem that you are considering? Not that slow logic can't have metastability problems, but in this case I wouldn't expect it. -- glenArticle: 153727
glen herrmannsfeldt wrote: > Frank Buss <fb@frank-buss.de> wrote: > > (snip) >> But you should latch the rx input, to avoid metastability problems. I >> don't know how to do this in Verilog, something like declare another reg >> with the name "rx", rename the raw input signal and copy it on rising >> clock edge to "rx". > > Can you explain the problem that you are considering? http://www.altera.com/literature/wp/wp-01082-quartus-ii-metastability.pdf > Not that slow logic can't have metastability problems, > but in this case I wouldn't expect it. My experience differs: I've used my simple UART receiver in a design with 115,200 baud, and without the buffer, the state machine halted (going to an invalid state, as I debugged with an "other" case branch, which was logically impossible) once every some hour. There was lots of high-speed logic behind the receiver and I've used only the classic timing analyzer of an old version of Quartus, so maybe in simpler designs, and with proper timing constraints for the rx signal, there would be no problem. But it is good design practice to buffer just any signal, which is fed asynchronously to the FPGA, then you don't have such problems, even if you didn't calculate and define all timing constraints. -- Frank Buss, http://www.frank-buss.de electronics and more: http://www.youtube.com/user/frankbussArticle: 153728
On Wed, 02 May 2012 00:46:56 +0200, Frank Buss wrote: > glen herrmannsfeldt wrote: >> Frank Buss <fb@frank-buss.de> wrote: >> >> (snip) >>> But you should latch the rx input, to avoid metastability problems. I >>> don't know how to do this in Verilog, something like declare another >>> reg with the name "rx", rename the raw input signal and copy it on >>> rising clock edge to "rx". >> >> Can you explain the problem that you are considering? > > http://www.altera.com/literature/wp/wp-01082-quartus-ii- metastability.pdf > >> Not that slow logic can't have metastability problems, but in this case >> I wouldn't expect it. > > My experience differs: I've used my simple UART receiver in a design > with 115,200 baud, and without the buffer, the state machine halted > (going to an invalid state, as I debugged with an "other" case branch, > which was logically impossible) once every some hour. There was lots of > high-speed logic behind the receiver and I've used only the classic > timing analyzer of an old version of Quartus, so maybe in simpler > designs, and with proper timing constraints for the rx signal, there > would be no problem. > > But it is good design practice to buffer just any signal, which is fed > asynchronously to the FPGA, then you don't have such problems, even if > you didn't calculate and define all timing constraints. It might be a good practice to have that "other" case statement feeding a master reset or some other more sensible response to a bad state than wedging the FPGA, too. Just sayin' -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.comArticle: 153729
In article <jnpp51$2vn$1@newsreader4.netcologne.de>, Frank Buss <fb@frank-buss.de> writes: >My experience differs: I've used my simple UART receiver in a design >with 115,200 baud, and without the buffer, the state machine halted >(going to an invalid state, as I debugged with an "other" case branch, >which was logically impossible) once every some hour. There was lots of >high-speed logic behind the receiver and I've used only the classic >timing analyzer of an old version of Quartus, so maybe in simpler >designs, and with proper timing constraints for the rx signal, there >would be no problem. It doesn't take metastability to do that. You will miss setup/hold if the signal has different timing paths to different FFs. One FF will see the old version of the signal and another FF will see the new version. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 153730
Tim Wescott <tim@seemywebsite.com> wrote: > On Wed, 02 May 2012 00:46:56 +0200, Frank Buss wrote: >> glen herrmannsfeldt wrote: >>> Frank Buss <fb@frank-buss.de> wrote: >>> (snip) >>>> But you should latch the rx input, to avoid metastability problems. I >>>> don't know how to do this in Verilog, something like declare another >>>> reg with the name "rx", rename the raw input signal and copy it on >>>> rising clock edge to "rx". >>> Can you explain the problem that you are considering? (snip) >>> Not that slow logic can't have metastability problems, >>> but in this case I wouldn't expect it. >> My experience differs: I've used my simple UART receiver in a design >> with 115,200 baud, and without the buffer, the state machine halted >> (going to an invalid state, as I debugged with an "other" case branch, >> which was logically impossible) once every some hour. OK, I suppose I could have looked at the actual logic before writing. Yes, if one isn't careful with a state machine, it can have metastability problems even with a slow clock. There is also that Quartus likes to rearrange state machines logic, such that it isn't like it is written. Some years ago, I found a bug in Quartus where it converted to a one-hot state machine even though I was using the state value in the design. (It had four states, and as written two state bits. Quartus converted to one-hot and gave two of the four as state bits.) >> There was lots of >> high-speed logic behind the receiver and I've used only the classic >> timing analyzer of an old version of Quartus, so maybe in simpler >> designs, and with proper timing constraints for the rx signal, there >> would be no problem. >> But it is good design practice to buffer just any signal, which is fed >> asynchronously to the FPGA, then you don't have such problems, even if >> you didn't calculate and define all timing constraints. Yes, if the design is such that more than one FF latches the same input, and can fail if different values are latched on the same clock cycle. > It might be a good practice to have that "other" case statement feeding > a master reset or some other more sensible response to a bad state than > wedging the FPGA, too. That seems to be the easy way to fix it. Now, it is likely that one additional clock cycle won't affect much, but one does have to consider that in terms of the overall logic. -- glenArticle: 153731
Hal Murray wrote: > In article <jnpp51$2vn$1@newsreader4.netcologne.de>, > Frank Buss <fb@frank-buss.de> writes: > >> My experience differs: I've used my simple UART receiver in a design >> with 115,200 baud, and without the buffer, the state machine halted >> (going to an invalid state, as I debugged with an "other" case branch, >> which was logically impossible) once every some hour. There was lots of >> high-speed logic behind the receiver and I've used only the classic >> timing analyzer of an old version of Quartus, so maybe in simpler >> designs, and with proper timing constraints for the rx signal, there >> would be no problem. > > It doesn't take metastability to do that. You will miss setup/hold > if the signal has different timing paths to different FFs. One > FF will see the old version of the signal and another FF will see > the new version. Right, this is slightly different from metastability, and maybe was the reason for the behaviour in my FPGA program, though the bugfix is the same :-) Is there a technical term for this special kind of problem? -- Frank Buss, http://www.frank-buss.de electronics and more: http://www.youtube.com/user/frankbussArticle: 153732
On 05/02/2012 12:46 AM, Frank Buss wrote: >>> But you should latch the rx input, to avoid metastability problems. I >>> don't know how to do this in Verilog, something like declare another reg >>> with the name "rx", rename the raw input signal and copy it on rising >>> clock edge to "rx". >> >> Can you explain the problem that you are considering? > > http://www.altera.com/literature/wp/wp-01082-quartus-ii-metastability.pdf > >> Not that slow logic can't have metastability problems, >> but in this case I wouldn't expect it. > > My experience differs: I've used my simple UART receiver in a design > with 115,200 baud, and without the buffer, the state machine halted > (going to an invalid state, as I debugged with an "other" case branch, > which was logically impossible) once every some hour. There was lots of > high-speed logic behind the receiver and I've used only the classic > timing analyzer of an old version of Quartus, so maybe in simpler > designs, and with proper timing constraints for the rx signal, there > would be no problem. Usually these problems are the result of an incoming asynchronous signal, like a UART RxD, going to two different inputs in the FPGA at the same time. When the signal has an undefined voltage right at the clock edge, one input could capture it as a '0', and the other input as a '1', potentially resulting in inconsistent states. Note that this has nothing to do with metastability.Article: 153733
In comp.arch.fpga, Frank Buss <fb@frank-buss.de> wrote: > Hal Murray wrote: >> >> It doesn't take metastability to do that. You will miss setup/hold >> if the signal has different timing paths to different FFs. One >> FF will see the old version of the signal and another FF will see >> the new version. > > Right, this is slightly different from metastability, and maybe was the > reason for the behaviour in my FPGA program, though the bugfix is the > same :-) > > Is there a technical term for this special kind of problem? Race condition -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) Experience varies directly with equipment ruined.Article: 153734
On Apr 30, 7:17=A0pm, Tim Wescott <t...@seemywebsite.com> wrote: > On Mon, 30 Apr 2012 00:22:50 +0000, Nico Coesel wrote: > > Giuseppe Marullo <giuseppe.marullonos...@iname.com> wrote: > > >>Hi all, > >>I am searching for the smallest/simpler UART in verilog. I need to > >>release the project under GPL and still confused about what are my > >>options. > > >>I would go with micro UART by Jeung Joon Lee but I am unable to > >>determine its license. > > >>There are others, like osvudu by Timothy Goddard seems released under > >>(a) MIT license, thus compatible with GPL. > > >>I need very simple stuff: > > >>baud rate 9600-115200 with a clock of about 100MHz but should be able t= o > >>run with other clocks, like 12MHz. No buffers and other fancy stuff. > > >>8N1, and possibility (I need some) to have rtx, tx and rx only > >>capability (I would like to instantiate just the parts I need). > > >>Don't know if I need fullduplex, possibly yes. > > >>What would you advice to use? > > > There is a very simple UART packed togethet with Xilinx's KCPSM. I agre= e > > with the others. Open Source UARTs are not always the best solution. I > > once used the 16550 UART from opencores but it is pretty crappy. Very > > slow due to an overly complex design. > > A design that did a good job of emulating the 16550 would have to be a > lot more complex than just a good asynchronous receiver-transmitter. > pair. =A0Particularly if you can hard-code the division ratio, bit count, > etc., they are easy-peasy thing to write. > > Certainly "overly complex" if you just need a serial interface -- but > maybe not so if you must have compatibility with existing software. > > (Note: I don't know at what point in the process one loses the > "universal" moniker -- but hard-coding all the bits that are normally > software programmable would seem to be it). > one "universal" thing I almost always use when I need a uart in an FPGA is to generate the baudrate with a DDS very simple and able to hit almost any baud rate at any clock rate -LasseArticle: 153735
On May 1, 8:11=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Tim Wescott <t...@seemywebsite.com> wrote: > > On Wed, 02 May 2012 00:46:56 +0200, Frank Buss wrote: > >> glen herrmannsfeldt wrote: > >>> Frank Buss <f...@frank-buss.de> wrote: > >>> (snip) > >>>> But you should latch the rx input, to avoid metastability problems. = I > >>>> don't know how to do this in Verilog, something like declare another > >>>> reg with the name "rx", rename the raw input signal and copy it on > >>>> rising clock edge to "rx". > >>> Can you explain the problem that you are considering? > > (snip) > > >>> Not that slow logic can't have metastability problems, > >>> but in this case I wouldn't expect it. > >> My experience differs: I've used my simple UART receiver in a design > >> with 115,200 baud, and without the buffer, the state machine halted > >> (going to an invalid state, as I debugged with an "other" case branch, > >> which was logically impossible) once every some hour. > > OK, I suppose I could have looked at the actual logic before writing. > > Yes, if one isn't careful with a state machine, it can have > metastability problems even with a slow clock. > > There is also that Quartus likes to rearrange state machines logic, > such that it isn't like it is written. Some years ago, I found a > bug in Quartus where it converted to a one-hot state machine even > though I was using the state value in the design. (It had four > states, and as written two state bits. Quartus converted to one-hot > and gave two of the four as state bits.) > > >> There was lots of > >> high-speed logic behind the receiver and I've used only the classic > >> timing analyzer of an old version of Quartus, so maybe in simpler > >> designs, and with proper timing constraints for the rx signal, there > >> would be no problem. > >> But it is good design practice to buffer just any signal, which is fed > >> asynchronously to the FPGA, then you don't have such problems, even if > >> you didn't calculate and define all timing constraints. > > Yes, if the design is such that more than one FF latches the same > input, and can fail if different values are latched on the same > clock cycle. > > > It might be a good practice to have that "other" case statement feeding > > a master reset or some other more sensible response to a bad state than > > wedging the FPGA, too. > > That seems to be the easy way to fix it. > > Now, it is likely that one additional clock cycle won't affect much, > but one does have to consider that in terms of the overall logic. > > -- glen Including a "when others =3D> state <=3D reset"; will not help unless you turn off state machine optimization, or invoke other "safe" state machine synthesis settings. One of the optimizations most any synthesizer worth its salt will do is remove "unreachable" states (those states that do not have a coded assignment or path to them.) Thus since "others" is not directly reachable, it gets optimized out, along with anything it was doing. There are multiple ways of dealing with this, most depend either on invoking synthesis tool settings or turning off state machine optimizations and manually handling it yourself in the RTL (such as with a "when others". Be careful though; some of the simplest to code methods result in the worst utilization and performance. However, it is best to handle the root of the problem, which is an improperly synchronized asynchronous input. The term for this problem is not "race condition" it is an "improper parallel synchronizer", or a circuit that clocks the same asynchronous input into more than one register in parallel. A "race condition" is when proper operation requires that one combinatorial path must be faster than another. AndyArticle: 153736
Tim Wescott <tim@seemywebsite.com> writes: >> But it is good design practice to buffer just any signal, which is fed >> asynchronously to the FPGA, then you don't have such problems, even if >> you didn't calculate and define all timing constraints. Mandatory, I'd say, unless you can make a cast-iron argument as to why it doesn't matter if it is sampled differently by two different flops. > > It might be a good practice to have that "other" case statement feeding a > master reset or some other more sensible response to a bad state than > wedging the FPGA, too. You'd think, wouldn't you? But ( at least in VHDL) you also have to be aware that synthesis tools (unless you do some hoop-jumping) are "clever" enough to "know" that you can't get to those invalid states (especially in VHDL when using an enumerated type: in language terms, anything outside the enumeration doesn't exist!). So they optimise out your nice recovery logic :( Quartus has an attribute to make the synth put its own reset logic in for invalid states, to go back to the reset state. XST has an attribute to specify the safe state it should go to when state is invalid. And another to enable that behaviour. Synplify has an option to generate logic to put things back to the reset state if an illegal state is detected. None of which makes the implementation match the code... Synplify also has an option to create an "exact" state machine, which does do precisely what your code says (or so it claims) at the expense of disabling all its clever optimisations for that machine. Take your pick :) Cheers, Martin > > Just sayin' -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.co.uk/capabilities/39-electronic-hardwareArticle: 153737
From my experience Ethernet is definitely a good way to do it (1000BASE-T). I have written a simple MAC layer on SP605 board (with PHY) which only deals with ARP, ICMP (for ping), and UDP protocols. I got approx. 50MBytes downloading speed(from PC to FPGA) with UDP (1024bytes payload). Uploading speed not measured though. But I think it should meet 20MBps requriement if software can catch and store the data quicker enough. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153738
Sorry I came in late for this one.
>`timescale 1ns/1ns
>
>module simulatedUartTransmitter(output reg TxD);
> time bitTime;
> //
> task setBitTime(input time newBitTime);
> bitTime = newBitTime;
> endtask
>
> task sendChar(input [7:0] char);
> begin
> // send start bit
> TxD = 0;
> // send eight data bits, LSB first
> repeat (8) begin
> #(bitTime) TxD = char[0];
> char = char >> 1;
> end
> // send stop bit
> #(bitTime) TxD = 1;
> #(bitTime);
> end
> endtask
> //
> initial TxD = 1; // line idles in "Mark" state
> //
>endmodule
>
>module justTryThisOne;
> // connections
> wire serial_TxD;
> // stimulus generator instance
> simulatedUartTransmitter txGenerator(.TxD(serial_TxD));
> //
> // There's no DUT in this example, but you can still
> // see the signal generator at work.
> //
> // code to generate some stimulus
> initial begin
> txGenerator.setBitTime(104000); // 9600Bd, roughly
> #1_000_000; // idle awhile before starting
> txGenerator.sendChar("h"); // ask the sig-gen...
> txGenerator.sendChar("i"); // ...to send some data
> txGenerator.sendChar("!"); // ...at our request
> #1_000_000; // idle awhile at the end
> end
>endmodule
I'm still quite new to VHDL external names. But I thought this is already
possible with VHDL-2008?
The simulatedUartTransmitter just looks like a package to me, with a few
procedures:
library ieee; use ieee.std_logic_1164.all;
package uartPkg is
type simulatedUartTransmitter is protected
procedure setBitTime(newBitTime:in time);
procedure sendChar(char:in character);
end protected simulatedUartTransmitter;
signal TxD:std_ulogic;
shared variable uartTx: simulatedUartTransmitter;
end package uartPkg;
package body uartPkg is
type simulatedUartTransmitter is protected body
variable bitTime:time;
procedure setBitTime(newBitTime:in time) is begin
bitTime:=newBitTime;
end procedure setBitTime;
procedure sendChar(char:in character) is begin
/* use wait statements to wait on bitTime. */
...
end procedure sendChar;
end protected body simulatedUartTransmitter;
end package body uartPkg;
/* The testbench. */
library ieee; use ieee.std_logic_1164.all;
entity justTryThisOne is end entity justTryThisOne;
architecture noTestbenchInst of justTryThisOne is
signal serial_TxD: std_ulogic;
alias txGenerator is <<variable @work.uartPkg.uartTx:
@work.uartPkg.simulatedUartTransmitter>>;
begin
tester: process is begin
txGenerator.setBitTime(104000);
wait for 1 us;
txGenerator.sendChar('h');
txGenerator.sendChar('i');
txGenerator.sendChar('!');
wait for 1 us;
end process tester;
end architecture noTestbenchInst;
I haven't tried this with any simulator, but it might just work.
regards, daniel
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 153739>One question though: if the task sendChar is called concurrently from >different procedural blocks in a way that the calls are overlapping, I >think the result would be a great mess (I am saying this as a not so great >lover of how Verilog works). > >Is there a simple way to deal with collisions like that? Or will the >simplicity be lost then for the most part? That's the reason why we have to use protected types to access methods/functions directly from a package or another entity. :) Peter Ashenden's book explains well... regards, daniel --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153740
Hi, I'd like to share with you my last development - a L3 protocol for transmission of data between low resources FPGA and an embedded system. It may allow you to use low cost/low resources FPGAs together with cheap Ethernet switches and simple Linux based embedded systems (or just reflashed Linux based Ethernet routers working as both a switch and an embedded system) to create data acquisition systems concentrating data from multiple channels. Because the Ethernet link does not provide reliable transfer of packet, we need to assure an acknowledge mechanism (like in TCP). However if the transfer speed is R bytes/second, and the maximum acknowledge latency is T, then we need to buffer at least R*T bytes. The problem is that at transfer rates of 100Mb/s or 1Gb/s the latency must be really small if we want to use only internal RAM of FPGA for buffering. E.g. for 100Mb/s (roughly 10MB/s) and 40kB of internal RAM, we can accept latency of only 4ms. For 1GB/s it could be only 400µs. To keep latency as low as possible, I've decided to implement my transmission as L3 protocol. As it is supposed to be used only in private networks, I have decided to use unregistered 0xfade Ethernet type. The sources of both: FPGA part (designed for Xilinx SP601 board, but written with portability in mind) and of Linux driver (compiled with kernel 3.3.3, but should work also with other 3.x kernels) are published on the alt.usenet group. See the post: "L3 protocol for data transmission from low resource FPGA to Linux embedded system" The link to the Google archive is: http://groups.google.com/group/alt.sources/browse_thread/thread/2c2511659f5869c5 I'll publish newer versions of my sources also on my website (yet almost empty): http://www.ise.pw.edu.pl/~wzab/fpga_l3_fade Generally the system is very simple. The kernel module may receive data from a few FPGA based "slave" devices (defined by the "max_slaves" parameters, when loading the module). Data received from each slave are written to the kernel buffer, which should be mmapped to the user application, which is supposed to preprocess the data and possibly send the result further through standard TCP/IP connections. The system of course doesn't handle routing (due to low latency requirements). The FPGA even doesn't need to handle ARP protocol. In the user application we need simply to register a slave with particular MAC connected to the particular network interface, and this slave will be visible as /dev/l3_fpga0, /dev/l3_fpga1 and so on. In my sources there is a very simple application, which connects to the slave, and verifies, that this slave sends consecutive integers. In system like this a nontrivial problem is to set the appropriate rate of packets sent from the slave to the embedded system. In my system it is achieved by introducing of certain delay between the data packets. This delay is adaptively adjusted during the operation of the system. The appropriate delay is found analysing the ratio between all sent packets and retransmitted packets: Nretr/Nall If the data packets are sent too quickly, the acknowledge packets from the embedded system are received too late, and the packet is retransmitted before acknowledge arrives. The same may occur if the embedded system is overloaded with packets from different slaves and drops some packets. Therefore if the Nretr/Nall is too high, we have to increase the delay. If the ratio Nretr/Nall is near to 0, we may reduce the delay. Such a simple algorithm works quite satisfactory. The sources are published partly under the GPL licence (the Linux driver and user application) and partly under the BSD license (my FPGA sources). Sources of FPGA part contain also very slightly modified Ethernet MAC http://opencores.org/project,ethernet_tri_mode which is published under LGPL. Unfortunately, I was not able to publish all parts generated by Xilinx tools, therefore I include only xco files. Please note, that my sources are the first iteration. They use some "quick and dirty" solutions. I hope to prepare more mature version and describe it in a normal publication (of course I'll send information about it, as I've done with my sorter: http://www.ise.pw.edu.pl/~wzab/fpga_heapsort, which was also first published in alt.sources and comp.arch.fpga ) I hope that my solution will be useful for somebody. -- Regards, Wojciech M. Zabolotny wzab@ise.pw.edu.plArticle: 153741
On Friday, May 4, 2012 3:39:27 AM UTC+8, daniel.kho wrote:
> /* The testbench. */
> library ieee; use ieee.std_logic_1164.all;
> entity justTryThisOne is end entity justTryThisOne;
>
> architecture noTestbenchInst of justTryThisOne is
> signal serial_TxD: std_ulogic;
> alias txGenerator is <<variable @work.uartPkg.uartTx:
> @work.uartPkg.simulatedUartTransmitter>>;
> begin
> tester: process is begin
> txGenerator.setBitTime(104000);
> wait for 1 us;
> txGenerator.sendChar('h');
> txGenerator.sendChar('i');
> txGenerator.sendChar('!');
> wait for 1 us;
> end process tester;
> end architecture noTestbenchInst;
Sorry, I guess serial_TxD should have been:
alias serial_TxD is <<signal @work.uartPkg.TxD: std_ulogic>>;
instead of declared as another signal within the architecture.
This way, you can check/monitor the output of the UART from this same testbench.
-daniel
Article: 153742Since the Beagleboard and the Raspberry Pi use Package-on-Packge for integr= ating Flash and DRAM with the processor SoC I wonder why the FPGA vendors d= o not offer this. There are many FPGA-designs that need external memory and= the pins to the base PCB are valuable resource.=20 Not even Silicon Blue (now lattice) who targeted the mobile market offered = it, as far as I could find.=20 Even though, the offered memories for PoP are limited, every new product th= at integrates with them would expand that spectrum.=20 With the new FPGA-SoCs (Xilinx ZYNC, Altera "SoC FPGA") the issue might cha= nge.=20 AndreasArticle: 153743
On Tuesday, 27 March 2012 12:10:18 UTC+1, Bill Valores wrote: > Hello all, > > My team needs to design our own piece of testing equipment for our > project. I'll spare you the gory details, and just say that we will > need to collect data at some 20 Mbyte/sec (possibly continuously) and > somehow get it to a PC computer running Windows. Hi Bill, See my post of the 28 May, or, to see it with embedded example YouTube videos, go see : FPGA Modular Firmware Skeleton for multiple instruments - Morph-IC-II, YouTube videos. http://www.element14.com/community/groups/fpga-group/blog/2012/04/28/fpga-modular-firmware-skeleton-for-multiple-instruments--morph-ic-ii-youtube-videos This does just what you want - 60MB.s-1 burst, (how much you get continuous depends on the PC and what else you are doing on the USB bus). It provides the USB interface to a group of instrument interfaces - what you build into each interface is up to you. Not free - very low price for individual use, a good value price for commercial use, would cost you much more to develop. You just need to talk to a .dll to drive it - example code for testing provided - See videos for example use. cheers, Dr. Beau WebberArticle: 153744
In article <pv5y5p9w6uy.fsf@trw.com>, Martin Thompson <martin.j.thompson@trw.com> writes: >Tim Wescott <tim@seemywebsite.com> writes: > >>> But it is good design practice to buffer just any signal, which is fed >>> asynchronously to the FPGA, then you don't have such problems, even if >>> you didn't calculate and define all timing constraints. > >Mandatory, I'd say, unless you can make a cast-iron argument as to why it >doesn't matter if it is sampled differently by two different flops. Even if you are sure it doesn't matter, you aren't out of the water yet. You still have to consider metastability. You also have to consider the design lifetime. Will the guy who changes something in this area several years from now be smart enough to know that he needs check again? Will he get it right? -- These are my opinions, not necessarily my employer's. I hate spam.Article: 153745
Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote: (snip) >> Mandatory, I'd say, unless you can make a cast-iron argument as >> to why it doesn't matter if it is sampled differently by >> two different flops. > Even if you are sure it doesn't matter, you aren't out of the water yet. > You still have to consider metastability. In most cases, for slow logic you don't. Metastability becomes a problem if the logic after the FF is long enough, and the FF is likely (ever) to be metastable long enough to cause problems. Note that you can never get rid of metastability, but only make it unlikely enough to cause a problem. In high speed designs, the logic delay is a significant part of a clock cycle, and even a short metastability can be long enough. > You also have to consider the design lifetime. Will the guy who > changes something in this area several years from now be smart > enough to know that he needs check again? Will he get it right? As with metastability, there is no way to avoid that. -- glenArticle: 153746
On Saturday, May 5, 2012 1:40:44 AM UTC+12, acd wrote: > Since the Beagleboard and the Raspberry Pi use Package-on-Packge for inte= grating Flash and DRAM with the processor SoC I wonder why the FPGA vendors= do not offer this. There are many FPGA-designs that need external memory a= nd the pins to the base PCB are valuable resource.=20 >=20 > Not even Silicon Blue (now lattice) who targeted the mobile market offere= d it, as far as I could find.=20 > Even though, the offered memories for PoP are limited, every new product = that integrates with them would expand that spectrum.=20 > With the new FPGA-SoCs (Xilinx ZYNC, Altera "SoC FPGA") the issue might c= hange.=20 >=20 > Andreas Xilinx has dropped some hints on this, but I think the bigger issue, is th= e FPGA is FAR LESS price sensitive, and MORE performance sensitive, than th= e products that use Stacked-Die. So, the top end FPGA's simply add more on chip RAM, and sell you a bigger = part!! You are quite right tho, that there is an opening for a smaller FPGA, or l= arger CPLD, tightly coupled to RAM. Even here, the issue is volume, as the really big players like Broadcom, c= an get good enough performance from their Stacked approach, to tackle 98% o= f the high volume markets - that leaves the crumbs for the PLD vendor.Article: 153747
In article <jo1lgf$e5r$1@speranza.aioe.org>, glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: >Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote: ... >> Even if you are sure it doesn't matter, you aren't out of the water yet. >> You still have to consider metastability. >In most cases, for slow logic you don't. Good point. Thanks. The key idea being "slow logic" where the metastability settling time is small relative to the cycle time. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 153748
On Wednesday, May 2, 2012 5:43:02 PM UTC+12, Frank Buss wrote: > Right, this is slightly different from metastability, and maybe was the > reason for the behaviour in my FPGA program, though the bugfix is the > same :-) > > Is there a technical term for this special kind of problem? My preference is to call it an Aperture Effect, as it is actually a small, but finite time window, and you can even calculate the width (in ns/ps) of this Aperture, given a large enough data-set sample size.Article: 153749
I know this is a question which is difficult to be answered, but does anyone have an estimate which Spartan-6 fpga has comparable 'size' as a xc2v1000 or a xc2v3000 fpga? With 'size' I don't mean chip dimensions, I mean logic functionality. A very rough estimate would be enough... Thanks, Thomas
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