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
Alex Freed <alex_news@mirrow.com> wrote: > No big surprise here: if they sell a cable worth about $10 in parts for > $250 they think it's good busyness. Doesn't take into account the loss > from bad PR this generates. > In any case there are now compatible Xilinx cable clones that are always > available on e-bay for around $70 or so. In addition my understanding is > that Digilent has a compatibility library now that allows their very > inexpensive USB cable to be used with Xilinx tools. Didn't try it myself > as I have both a genuine Xilinx cable and a clone from China that works > just as well just in case. This doesn't help if for some reason (e.g. high speed UBS transfer) you already have some device that handles USB access and could handle JTAG. To plug in the DLC(clone) you need another connector ... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 144501
Ben Jones wrote: > I still maintain that asynchronous reset "isn't the best solution", > but everything Andy says is certainly true. Sometimes, you have an > external requirement for it, and in most cases the FPGA silicon and > tools will cope with it. But note that in more complex designs and on > some devices, certain blocks (e.g. DSPs, BRAMs) contain registers that > are only resetable synchronously. True, but it simplifies simulation having a reset for the input and output registers, even if (especially if ?) the rams and some shifters don't have one. The reset can always be tied inactive if it is not needed in the system. But it does help me on the front end, and is always there if I need it. There is also value for me in using the same design rules every time. -- Mike TreselerArticle: 144502
Joshi & Joshi wrote:
> thanks a lot for all your inputs ...
> the asynchronous reset i synthesized already
> but the problem is in simulaton ...
> please correct my Code ..
Here's my take on Andy's clever idea.
Untested, but compiles and should be close.
-- Mike Treseler
__________________________________________________________________
package period_pkg is -- idea from Andy
-- To account for uneven half cycles:
constant input_f : integer := 40000000;
constant output_f : integer := 1200;
constant period : integer
:= (input_f + output_f / 2) / output_f;
-- round up
constant high : integer := (period + 1) / 2;
constant low : integer := period - high;
end package period_pkg;
------------------------------------------------------------------
use work.period_pkg.all;
library ieee;
use ieee.std_logic_1164.all;
entity period is
port (
in_clk, rst : in std_ulogic;
out_clk : out std_ulogic);
end entity period;
architecture period of period is
-- Fri Dec 11 09:47:27 2009 mtreseler
begin -- architecture period
p : process(in_clk, rst) is
variable clk_cnt_v : integer range 0 to high - 1;
variable out_clk_v : std_ulogic;
begin
if rst = '1' then
------------------------------------------------------------------
-- init regs
out_clk_v := '0';
clk_cnt_v := 0;
elsif rising_edge(in_clk) then
------------------------------------------------------------------
-- update regs
roll:if clk_cnt_v = 0 then
load:if out_clk_v = '1' then
clk_cnt_v := low - 1; -- load low half-period
else
clk_cnt_v := high - 1; -- load high half_period
end if load;
toggle:out_clk_v := not out_clk_v;
else
decr:clk_cnt_v := clk_cnt_v - 1;
end if roll;
end if;
------------------------------------------------------------------
-- update ports:
ports:out_clk <= out_clk_v;
end process p;
end architecture period;
Article: 144503kendor <jonas.reber@bfh.ch> wrote: > for a measuring utility (running @ 100MHZ) I need a counter of 42-bit width > whose value is used by several sub blocks of my design. As a first, somehow > dirty solution I have implemented this like follows. Since this approach > needs quite a huge amount of FFs and leads to long delaytimes (bit 0 to 42) > I am looking for an alternative. I was thinking about using Block RAM > (Spartan3) to reduce routing effort and delaytimes. (see also > http://courses.ece.illinois.edu/ece412/References/datasheets/xapp463.pdf) Someone else suggested a LFSR which seems like it might work. It depends somewhat on what you do with the count later. I was just thinking that you could cascade counters with a latch between the carry out of one and the carry in of the next. That causes the carry to occur one cycle late, which results in a strange count sequence, but fairly easy to correct externally. Though propagating the value to other subblocks seems likely to take about as long as getting the carry through 42 bits. That might require more pipeline registers throughout the design. Otherwise, 50MHz or 25MHz should be easy. A one or two bit counter at 100MHz with the appropriate logic to generate and latch a carry signal should also work. -- glenArticle: 144504
thranduil <vlasinac@gmail.com> wrote: > i want to buy Spartan 3E starter kit and I am wonder if someone managed to > make it works like a standard USB device. Take a look at the Demand Peripherals BaseBoard4. It has a USB interface to the host and appears as a USB serial port. The USB serial port is used for downloading the FPGA code and then the port is available as a communication channel between the host and the FPGA. There was an article in the February issue of Nuts and Volts magazine about this board. Google for "FPGAs at the Command Line" to find it. (BTW: I wrote the article.) HTH Bob SmithArticle: 144505
On Dec 4, 10:15=A0am, "kendor" <jonas.re...@bfh.ch> wrote: > hello there > > for a measuring utility (running @ 100MHZ) I need a counter of 42-bit wid= th > whose value is used by several sub blocks of my design. > kendor The conventional design of a synchronous counter would concatenate 42 flip-flops, using the built-in dedicated carry chain. Its carry propagation delay is extremely short, but the total delay might be too long for 100 MHz operation. You can maintain the synchronous nature of the design, but decode an additional count enable from the first 2 flip-flops and route that signal to all the remaining 40 flip-flops in parallel. That gives the long carry chain not 10 ns, but 40 ns to stabilize, which is more than sufficient. And you still have a totally synchronous counter where all bits change on the same clock. If you think that 42 flip-flops are too many, you can use BlockRAMs. Each dual-ported 4K BlockRAM can implement an 8-bit counter per port, easily concatenated to 16 bits per BRAM. (The two ports have the same look-up functionality, just different addressing inputs, fed back from the own outputs) Two BlockRAMs can thus form a 32-bit fully synchronous counter, and a third BRAM can extend that to 48 bits. There is some trickery in gating the carry signals, but it never involves more than one level of combinatorial logic, no problem at 100 MHz. And you can also of course always use a pre-scaler, as described above. Now, if you use more modern FPGAs, like Spartan3DSP, or Spartan6, or Virtex4,5,or 6, then you can use the ready-made 48-bit accumulator (an accumulator that adds 1 per clock tick is a counter) without any design effort at all, and a speed of up to 500 MHz. Old FPGA families may sometimes look cheaper, but that may be deceptive. Would you today buy a car with drum brakes, no fuel injection, no CD player, no airbags and no air conditioning ? Peter AlfkeArticle: 144506
interesting. I'll try a chipscope demo... Thanks On Dec 9, 6:48=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > Andy Peters <goo...@latke.net> writes: > > On Dec 7, 6:26=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > >> laserbeak43 <laserbea...@gmail.com> writes: > >> > Hello, > >> > =A0 =A0 I've just been shownSignaltap, A feature inQuartusWebpack > >> > Edition. Does the Webpack Edition of ISE have this feature? WOW this > >> > alone can convince me to use Altera products. > > >> Chipscope is theXilinxequivalent - it's not in webpack (personally, I > >> think that's a mistake onXilinx'spart) > > >> But comparing it toSignaltapmay (IMHO) leave you underwhelmed... it's > >> very disjointed and unintegrated in comparison. =A0I'm still using FPG= A > >> editor to change which signals to monitor, then having to update the > >> viewer by hand! V. tedious. > > > Really? Whatversionof ChipScope are you using? > > 10.1.3 > > > > > Use the ChipScope Core Inserter. > > Indeed, I could (and have in the past), but > > a) I'm using the EDK variety of core inserter, as it manages the JTAG > linkages with the microblaze debug module for me > > b) I then have to run MAP, PAR, bitgen again. > > > All of the signals and elements of > > the design are shown in it, and you simply choose the signals to > > monitor. After you close the Inserter, go back to ISE, and re-fit. > > Re-fit - 10s of minutes. > > > From the ChipScope viewer, you can reconfigure the FPGA, then do an > > "Import" which lets you bring in the names of all of the signals you > > selected from the ChipScope Core Inserter project file. > > > No need to go into the FPGA editor at all! > > FPGAeditor, regenerate bitstream, 10s of seconds... =A0Then click "write > CDC" button, import the result into the analyser. =A0Still tedious :) > > As I recall my experience withSignalTap(which was a while ago > admittedly) I could select a signal from a dropdown list *in the > Analyser* and it would do the tedious hacking that I currently do in > FPGAed, regen the bitstream and upload it for me. > > Under some circumstances, it would redo a fit at that point, which was > irritating, but at least I was able to do it all from the analyzer GUI, > which was then always in sync with the FPGA. > > [Followups set to comp.arch.fpga, as it's not very Veriloggy] > > Cheers, > Martin > > Crosspost & Followup-To: comp.arch.fpga > -- > martin.j.thomp...@trw.com > TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://w= ww.conekt.net/electronics.htmlArticle: 144507
Hi all, I am presently doing post route timing simulations using net-list and sdf file. I built test benches and done functional simulations and all are working fine and expecting expected results When i am running timing simulations for Min, Typ, Max, here i am getting simulation results from the waveforms for Typ, Max, but Min case my simulation is running up to some steps (where i can observe in waveform) and after some time bus is idle and no more simulation is happening. I am giving run time simulation in well; i mean at least double the original time. Is that i have to change any settings in Modelsim or any other process to run this case. Please anyone give some knowledge on this issue. ThanksArticle: 144508
Joshi & Joshi wrote: > Hello to all > > i have master Clock 40 Mhz and from master Clock want Generate 1.2 K > hz Suare wave pulses at output > > (1) what is problm with my Code > (2) how Counter works and how to take decide the Counter values like > these designs > (3) without Counter can we use Shift ?? > > my code is as below > library ieee; > use ieee.std_logic_1164.all; > use ieee.std_logic_arith.all; > use ieee.std_logic_unsigned.all; > > entity Clk_divider is > port( > resetn : in std_logic; -- Reset > MHZ_clock : in std_logic; > Out_clock : out std_logic > > ); > end Clk_divider; > > architecture Clk_divider_arch of Clk_divider is > > signal clk_count : std_logic_vector(16 downto 0) := > "00000000000000000"; -- 16 Bit Counter > > begin > > Clock : process(resetn, MHZ_clock) -- 0.025uSec > begin > if(resetn = '0') then > Out_clock <= '0'; > > elsif(MHZ_clock'event and MHZ_clock = '1') then > if(clk_count <= "01000001000101000") then --- want Generate > Delay (40M Hz /1.2K Hz = 3320) > clk_count <= clk_count + '1'; > out_clock <= '1'; > > elsif(( clk_count > "01000001000101000") AND (clk_count < > "10000010001010000"))then > -- 0 to 3333 ON and 3333 to 6666 OFF > > out_clock <= '0'; > clk_count <= clk_count + '1'; > if(clk_count = "10000010001010000") then > clk_count <= "00000000000000000" ; > > end if; > end if ; > > end if ; > end process Clock ; > end Clk_divider_arch ; > > Waiting fr replies .. > > with Advance Thanks > Joshi Homework?Article: 144509
Hi, Would wire 'a' in this case be glitch free if: 1) count[0] comes out of a flip flop. 2) I can garantee that 'count[0]' is stable when 'b' is changing (but 'count[0]' might be high or low). 3) when 'b' is stable, I want to be able to toggle 'a' using 'count[0]' glitch free as well. 4) 'b' is a fully asynchronous signal wire a = b ? 1 : count[0]; I'm using a Spartan3 FPGA. Thanks, Diego --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144510
On Dec 12, 4:54=A0am, JSreeniv <sreenivas.jyo...@gmail.com> wrote: > observe in waveform) and after some time bus is idle and no more > simulation is happening. I am giving run time simulation in well; i > mean at least double the original time. You shouldn't need to run for any simulation time longer than you do for simulating - Original code - Max time - Typ time > > Is that i have to change any settings in Modelsim or any other process > to run this case. Why are the tools are the first suspect? With almost 100% certainty, the problem is one of the following: - Your original code - Possibly (but I would guess much less likely) the post route model has some problem with the min timimg) > Please anyone give some knowledge on this issue. > The problem is most likely in your code. Since typ and max work I would suspect that you have one (or more) of the following design issues that need to be fixed. - Incorrectly handled clock domain crossing - Latches or other combinatorial logic loops The easier way to find this is to perform static timing analysis. The harder way is to use the simulator. Also, even if the simulator does work with min, typ and max it does not imply that your design does not have a timing problem. The only way to insure that is through static timing analysis. Kevin JenningsArticle: 144511
I will add that our new USB based Prog3 is now working. This cable will work with Impact and Chipscope. We do have some more tests to do after which we will release to sell generally with our products. Expect this to be available in January sometime. John Adair Enterpoint Ltd. On 8 Dec, 22:43, John Adair <g...@enterpoint.co.uk> wrote: > A number of parallel port based cables, like our Prog2 cable, will > work for Chipscope/Impact tools. USB solutions are not readily > available as yet unless you are a student where there is an option for > a cheaper cable. We may offer something of a solution in a little > while but remains to be debugged as yet. > > John Adair > Enterpoint Ltd. > > On 8 Dec, 20:35, "dlopez" <d...@designgame.ca> wrote: > > > Hi, > > It seems like Chipscope only supports the original Xilinx cable...no ot= her > > JTAG cable would work. Anyone knows if there is a way to obtain one for > > less than the very high 250$ they ask for? > > > Thanks, > > > Diego =A0 =A0 =A0 > > > --------------------------------------- =A0 =A0 =A0 =A0 > > This message was sent using the comp.arch.fpga web interface onhttp://w= ww.FPGARelated.comArticle: 144512
Thanks everyone for the feedback...I ended up getting the Digilent cable since it's so cheap. It was news to me that this cable would support chipscope. It sure is better than 250$! Diego --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144513
You still will need to make sure you meet setup and hold to avoid glitches. If the system allows it would be better to put ;b; into the same clock domain. Running as fast a clock as you can can minimise this inducted jitter of an edge. With careful design and keeping it simple you could probably run a 200Mhz clock giving a jitter window of 5 nS by synchronising 'b'. John Adair Enterpoint Ltd. On 12 Dec, 15:52, "dlopez" <d...@designgame.ca> wrote: > Hi, > > Would wire 'a' in this case be glitch free if: > > 1) count[0] comes out of a flip flop. > 2) I can garantee that 'count[0]' is stable when 'b' is changing (but > 'count[0]' might be high or low). > 3) when 'b' is stable, I want to be able to toggle 'a' using 'count[0]' > glitch free as well. > 4) 'b' is a fully asynchronous signal > > wire a =3D b ? 1 : count[0]; > > I'm using a Spartan3 FPGA. > > Thanks, > Diego =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > This message was sent using the comp.arch.fpga web interface onhttp://www= .FPGARelated.comArticle: 144514
On Sat, 12 Dec 2009 09:52:10 -0600, "dlopez" <d@designgame.ca> wrote: >Would wire 'a' in this case be glitch free if: > >1) count[0] comes out of a flip flop. >2) I can garantee that 'count[0]' is stable when 'b' is changing (but >'count[0]' might be high or low). >3) when 'b' is stable, I want to be able to toggle 'a' using 'count[0]' >glitch free as well. >4) 'b' is a fully asynchronous signal > >wire a = b ? 1 : count[0]; > >I'm using a Spartan3 FPGA. As John Adair hinted, the only truly safe way to do this is synchronously - which you've indicated is not possible. There is no fundamental reason to assume that ANY combinational logic will be glitch-free in a LUT-based FPGA. In such FPGAs your 2-input OR gate (for that is what it is) will be implemented in a LUT. That means the LUT's address decoder will be changing when either of the two inputs b,count[0] changes; and, in principle, all bets are off about glitches. In practice the LUTs seem very well behaved, and Xilinx experts may be able to tell you how to do this in a way that's guaranteed glitch-free. Personally, though, I wouldn't bet my life on it. Find a solution that doesn't depend on freedom from glitches at that level. -- Jonathan BromleyArticle: 144515
On Dec 12, 8:07=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Sat, 12 Dec 2009 09:52:10 -0600, "dlopez" <d...@designgame.ca> wrote: > >Would wire 'a' in this case be glitch free if: > > >1) count[0] comes out of a flip flop. > >2) I can garantee that 'count[0]' is stable when 'b' is changing (but > >'count[0]' might be high or low). > >3) when 'b' is stable, I want to be able to toggle 'a' using 'count[0]' > >glitch free as well. > >4) 'b' is a fully asynchronous signal > > >wire a =3D b ? 1 : count[0]; > > >I'm using a Spartan3 FPGA. > > As John Adair hinted, the only truly safe way to do this is > synchronously - which you've indicated is not possible. > > There is no fundamental reason to assume that ANY combinational > logic will be glitch-free in a LUT-based FPGA. =A0In such FPGAs your > 2-input OR gate (for that is what it is) will be implemented in > a LUT. =A0That means the LUT's address decoder will be changing > when either of the two inputs b,count[0] changes; and, in > principle, all bets are off about glitches. =A0In practice the > LUTs seem very well behaved, and Xilinx experts may be able > to tell you how to do this in a way that's guaranteed glitch-free. > Personally, though, I wouldn't bet my life on it. =A0Find a solution > that doesn't depend on freedom from glitches at that level. > -- > Jonathan Bromley I am almost sure Xilinx claims the LUT output is glitch-free (under all conditions) AnttiArticle: 144516
Jonathan Bromley <jonathan.bromley@mycompany.com> wrote: > On Sat, 12 Dec 2009 09:52:10 -0600, "dlopez" <d@designgame.ca> wrote: >>Would wire 'a' in this case be glitch free if: >>1) count[0] comes out of a flip flop. >>2) I can garantee that 'count[0]' is stable when 'b' is changing (but >>'count[0]' might be high or low). >>3) when 'b' is stable, I want to be able to toggle 'a' using 'count[0]' >>glitch free as well. >>4) 'b' is a fully asynchronous signal >>wire a = b ? 1 : count[0]; >>I'm using a Spartan3 FPGA. > As John Adair hinted, the only truly safe way to do this is > synchronously - which you've indicated is not possible. I think asking about glitches indicates the desire to not use synchronous logic. While most people do, not everyone does. > There is no fundamental reason to assume that ANY combinational > logic will be glitch-free in a LUT-based FPGA. In such FPGAs your > 2-input OR gate (for that is what it is) will be implemented in > a LUT. That means the LUT's address decoder will be changing > when either of the two inputs b,count[0] changes; and, in > principle, all bets are off about glitches. I will see what Xilinx says about this. There are too many cases in current designs where glitches like this would cause problems. Now, changing two LUT inputs is likely to glitch if you can't guarantee the intermediate states. It might be, though, that the decoders are implmented as two input MUX such that changing one input won't glitch. If you change more than one and the intermediate states are consistent such that there is no glitch for any order (which you likely can't predict) then it also shouldn't glitch. All that really matters, though, is that any glitches are faster than subsequent logic can see. (Considering, for example, input capacitance and drive strength.) > In practice the > LUTs seem very well behaved, and Xilinx experts may be able > to tell you how to do this in a way that's guaranteed glitch-free. > Personally, though, I wouldn't bet my life on it. Find a solution > that doesn't depend on freedom from glitches at that level. -- glenArticle: 144517
Alright I guess I should have posted what I was trying to do in the first place...maybe the asynchronous way is just not the way to go. I'm designing the interface with the FT2232H chip in Asynchronous Fifo Mode. I want to maximize throughput. The timing diagram is on page26, figure 4.5: http://ftdichip.com/Documents/DataSheets/DS_FT2232H_V206.pdf RXF: fully asynchronous input to FPGA RD#: output from FPGA D[7:0]: input to FPGA, needs to be grabbed when RD# goes high. Now this has to be the most confusing timing diagram in the world, but after hours of starring at it, I think I got it: 1)RXF goes low 2)FPGA drives RD# low...need to stay low 50ns 3)FPGA drives RD# high and grab the data. 4)RXF will stay low up to 25ns, then go high. It will stay high UP TO 67ns(but could be less). 5)When RXF goes low again, we repeat this sequence. What I'm struggling with is that when RXF goes low, the FPGA should bring RD# low AS SOON AS POSSIBLE. Any time spent synchronizing RXF is wasted time that would reduce throughput. Any ideas? Thanks, Diego --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144518
On Dec 12, 11:12=A0am, "dlopez" <d...@designgame.ca> wrote: > Alright I guess I should have posted what I was trying to do in the first > place...maybe the asynchronous way is just not the way to go. > > I'm designing the interface with the FT2232H chip in Asynchronous Fifo > Mode. I want to maximize throughput. The timing diagram is on page26, > figure 4.5: > > http://ftdichip.com/Documents/DataSheets/DS_FT2232H_V206.pdf > > RXF: fully asynchronous input to FPGA > RD#: output from FPGA > D[7:0]: input to FPGA, needs to be grabbed when RD# goes high. > > Now this has to be the most confusing timing diagram in the world, but > after hours of starring at it, I think I got it: > > 1)RXF goes low > 2)FPGA drives RD# low...need to stay low 50ns > 3)FPGA drives RD# high and grab the data. > 4)RXF will stay low up to 25ns, then go high. It will stay high UP TO > 67ns(but could be less). > 5)When RXF goes low again, we repeat this sequence. > > What I'm struggling with is that when RXF goes low, the FPGA should bring > RD# low AS SOON AS POSSIBLE. Any time spent synchronizing RXF is wasted > time that would reduce throughput. > > Any ideas? > Thanks, > Diego > > --------------------------------------- =A0 =A0 =A0 =A0 > This message was sent using the comp.arch.fpga web interface onhttp://www= .FPGARelated.com I have answered this particular question dozens of times while I was working at Xilinx. Today, I googled for "lut glitches" and here is what I found: http://www.castalk.com/ftopic12373.html In short: changing a SINGLE lut input will NEVER generate a glitch. Peter Alfke, quoting himself.Article: 144519
On Dec 12, 2:12=A0pm, "dlopez" <d...@designgame.ca> wrote: > Alright I guess I should have posted what I was trying to do in the first > place...maybe the asynchronous way is just not the way to go. > With FPGAs going synchronous design is usually the best... > I'm designing the interface with the FT2232H chip in Asynchronous Fifo > Mode. I want to maximize throughput. The timing diagram is on page26, > figure 4.5: > > http://ftdichip.com/Documents/DataSheets/DS_FT2232H_V206.pdf > Yes, I see it...it immediately follows figure 4.4 and the description on pages 24 and 25 of SYNCHRONOUS Fifo mode operation... > > What I'm struggling with is that when RXF goes low, the FPGA should bring > RD# low AS SOON AS POSSIBLE. Any time spent synchronizing RXF is wasted > time that would reduce throughput. > > Any ideas? In the end, asynchronous mode operation of the fifo will never be able to come close to getting the throughput that you can get with synchronous mode operation. For this particular part, it looks like you can clock the fifo at 60 MHz for synchronous mode. For async operation, the theoretical best performance (and not actually achievable in any real design because it assumes zero prop delay, PCB delay, setup or hold time) is a clock period of T1 (=3D50 ns) + T2 (=3DT5 + T6 =3D 0 + 33 ns) for a total of 83 ns...5 times slower than synchronous mode...and not achievable either. In reality you'd probably be lucky to get the whole thing to run with a 100 ns clock...6 times slower than synchronous mode. You say you want to get the data 'as soon as possible', but that's not a real requirement. Do the analysis and figure out what sort of performance you actually need. Then you can decide whether the ~10 MHz operation of async mode operation is acceptable. If not, then you'll have to run the fifo synchronously. Kevin JenningsArticle: 144520
>With FPGAs going synchronous design is usually the best... > >> I'm designing the interface with the FT2232H chip in Asynchronous Fifo >> Mode. I want to maximize throughput. The timing diagram is on page26, >> figure 4.5: >> >> http://ftdichip.com/Documents/DataSheets/DS_FT2232H_V206.pdf >> > >Yes, I see it...it immediately follows figure 4.4 and the description >on pages 24 and 25 of SYNCHRONOUS Fifo mode operation... > >> >> What I'm struggling with is that when RXF goes low, the FPGA should bring >> RD# low AS SOON AS POSSIBLE. Any time spent synchronizing RXF is wasted >> time that would reduce throughput. >> >> Any ideas? > >In the end, asynchronous mode operation of the fifo will never be able >to come close to getting the throughput that you can get with >synchronous mode operation. > >For this particular part, it looks like you can clock the fifo at 60 >MHz for synchronous mode. For async operation, the theoretical best >performance (and not actually achievable in any real design because it >assumes zero prop delay, PCB delay, setup or hold time) is a clock >period of T1 (=3D50 ns) + T2 (=3DT5 + T6 =3D 0 + 33 ns) for a total of 83 >ns...5 times slower than synchronous mode...and not achievable >either. In reality you'd probably be lucky to get the whole thing to >run with a 100 ns clock...6 times slower than synchronous mode. > >You say you want to get the data 'as soon as possible', but that's not >a real requirement. Do the analysis and figure out what sort of >performance you actually need. Then you can decide whether the ~10 >MHz operation of async mode operation is acceptable. If not, then >you'll have to run the fifo synchronously. > >Kevin Jennings > I agree with your worst case calculations, and they align with what FTDI claim for the Async mode (10MB/s). However, there are two things to consider: 1)the sync fifo is more like 25MB/s sustained (it bursts out at 60, but in the end you get 25). 2)the async FIFO has TWO channels, at say 10MB/s. So overall it might be a bit less, but the fact that the two channels run in parallel GREATLY simplify my system since I can separate control and streaming data. Now I'm REALLY struggling to get the state machine with 3 states to run at more than 100MHZ!!! Diego --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144521
On Sat, 12 Dec 2009 11:26:54 -0800 (PST), Peter Alfke <alfke@sbcglobal.net> wrote: >In short: >changing a SINGLE lut input will NEVER generate a glitch. Nice to know, and - thinking about the likely structures for the guts of a LUT - perfectly reasonable. Thanks. However.... can all other manufacturers of LUT-based FPGAs make the same promise? Again, *probably* yes; but would you bet your life/reputation/fortune on it? -- Jonathan BromleyArticle: 144522
On Sat, 12 Dec 2009 01:54:23 -0800 (PST), JSreeniv <sreenivas.jyothi@gmail.com> wrote: >Hi all, > >I am presently doing post route timing simulations using net-list and >sdf file. > Does the post-route timing report have any violations? Before you run post-route simulations you need to make sure you have proper timing constraints and your post-route timing is clean. >I built test benches and done functional simulations and all are >working fine and expecting expected results > >When i am running timing simulations for Min, Typ, Max, here i am >getting simulation results from the waveforms for Typ, Max, >but Min case my simulation is running up to some steps (where i can >observe in waveform) and after some time bus is idle and no more >simulation is happening. I am giving run time simulation in well; i >mean at least double the original time. For properly designed circuits min, max and typ behavior should be identical. Even if your simulation completed with longer run times, it would mean there is still a violation (there might be some timing dependency on synchronization paths for clock domain crossings but this should be rare and bounded in time). One other thing you can check is the timing simulation log. Are there any timing violations reported? Min timing problems suggest that there might be some hold violations. Look at the log which comes out while running your simulation and check if any hold violations are being reported. Another option you can try is to run your timing simulation with "no timing checks" option in your simulator and see if that completes properly. If the simulation runs properly with "+notimingchecks" option then it's almost guaranteed that you have some timing violations which need to be fixed. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 144523
On Dec 12, 3:46=A0pm, "dlopez" <d...@designgame.ca> wrote: > However, there are two things to consider: > 1)the sync fifo is more like 25MB/s sustained (it bursts out at 60, but i= n > the end you get 25). That's because the part runs out of data (read) or can't send it out fast enough (write). The effective throughput is limited by how well the USB engine and whatever is on the other end can transfer data, not because of some inherent issue with the synchronous interface. > 2)the async FIFO has TWO channels, at say 10MB/s. So overall it might be = a > bit less, but the fact that the two channels run in parallel GREATLY > simplify my system since I can separate control and streaming data. > OK, but then if you have a justification for why you''re willing to sacrifice performance you shouldn't worry too much about limiting it a bit more by your choice of data connection. > Now I'm REALLY struggling to get the state machine with 3 states to run a= t > more than 100MHZ!!! Using the synchronous protocol you'd only need to run at 60 MHz. Good luck, sounds challenging and that always makes life interesting. Kevin JenningsArticle: 144524
> The data2mem tool doesn't require you to know the physical location of > a particular BlockRAM, it just needs to know what the name is like a > UCF file does.http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/data2... Thanks! I'm still confused since that manual says (page 28) "The BMM file <i>must</i> have LOC or PLACED constraints for each block RAM. These constraints can be added manually, but they are most often obtained as an annotated BMM file from Bitgen. For information, see Using Integrated ISE(R) Design Suite Implementation Tools." I think that is in reference to the "-bd" option to bitgen, but as far as I can tell, that still needs to have physical location constraints for the blockrams (page 33) "Placement information of each block RAM is provided by teh NCD file. Any block RAM placement constraints that appear in the BMM file are already reflected in the NCD information. All othe rblock RAMs are assigned placement constraints by previous tool steps." I was originally using generic VHDL code to get XST to infer the blockrams, and I couldn't figure out how to refer to them in constraints, but I've given up on using inference and am now instantiating RAMB16_S9 primitives. Eric
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