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
rickman <gnuarm@gmail.com> wrote: (snip, I wrote) >> I suppose that is true, but really it shouldn't be a problem. >> It is usual for many systems to clock as fast as you can, >> consistent with the critical path delay. As metastability >> is exponential, even a slightly shorter delay is usually enough >> to make enough difference in the exponent. >> That assumes that there is a FF to FF path that is faster than >> the FF logic FF path. I believe that is usual for FPGAs, but >> if you manage to get a critical path with only one LUT, then >> I am not so sure. But that is pretty hard in most real systems. (snip) > You keep talking about the critical path delay as if the metastable > input is driving the critical path. There is only one critical path > in a design normally. All other paths are faster. Are you assuming > that all paths have the same amount of delay? No, but it might be that many have about the same delay. Well, my favorite things to design are systolic arrays, where there is the same logic (though with different routing, different delay) between a large number of FFs. For any pipelined processor, the most efficient logic has about the same delay between successive registers. > Regardless, all I am saying is that you don't need to use a path that > has no logic to obtain *enough* slack to give enough settling time to > the metastable input. But in all cases you need to verify this. Yes. One would hope that no logic would have the shortest delay, though in the case of FPGAs, you might not be able to count on that. > As mentioned in another post, Peter Alfke's numbers show that you only > need about 2 ns to get 100 million years MTBF. Of course whether this > is good enough depends on just how reliable your systems have to be > and how many there are. It is 100 million years for one unit, but for > 10 million units it will only be 10 years MTBF for the group. I have done designs with at most two LUTs between registers, and might even be able to do one. -- glenArticle: 154001
On Mon, 09 Jul 2012 17:20:26 -0700, rickman wrote: > On Jul 9, 2:35 pm, Tim Wescott <t...@seemywebsite.com> wrote: >> On Sun, 08 Jul 2012 15:38:45 -0700, rickman wrote: >> > On Jul 6, 10:00 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal >> > Murray) wrote: >> >> In article <nZ-dnch1rrNvHG_SnZ2dnUVZ_qSdn...@web-ster.com>, >> >> Tim Wescott <t...@seemywebsite.please> writes: >> >> >> >Paranoid logic designers will have a string of two or three >> >> >registers to avoid metastability, but I've been told that's not >> >> >necessary. (I'm not much of a logic designer). >> >> >> Ahh, but are they paranoid enough? >> >> >> The key is settling time. >> >> >> In the old days of TTL chips, a pair of FFs (with no logic in >> >> between) got you settling time of as much logic as the worst case >> >> delay for the rest of the system. In practice, that was enough. >> >> >> With FPGAs, routhing is important. A pair of FFs close together is >> >> probably good enough. If you put them on opposite sides of a big >> >> chip, the routing delays may match the long path of the logic delays >> >> and eat up all of your slack time. >> >> >> Have any FPGA vendors published recent metastability info? (Many >> >> thanks to Peter Alfke for all his good work in this area.) >> >> >> I'm not a silicon wizard. Is it reasonable to simulate this stuff? >> >> I'd like to know worst case rather than typicals. It should be >> >> possible to do something like verify simulations with lab typicals >> >> and then use simulations to find the numbers for the nasty corners. >> >> > I'm not sure what you would want to simulate. Metastability is >> > probabilistic. There is For a given length of settling time there is >> > some probability of it happening. Increasing the settling time >> > reduces the probability but it will never be zero meaning there is no >> > max length of time it takes for the output of a metastable ff to >> > settle. >> >> The drivers of metastability are probabilistic, yes. But given enough >> information you could certainly simulate the positive feedback loop >> that is a flip-flop. >> >> I suspect that unless the ball that is the flip-flop state is poised >> right on the top of the mountain between the Valley of Zero and the >> Valley of One, that the problem is mostly deterministic. It's only >> when the after-strobe balance is perfect and the gain is so low that >> the FF voltage is affected more by noise than by actual circuit forces >> that the problem would remain probabilistic _after_ the strobe >> happened. >> >> "Enough information", in this case, would involve a whole lot of deep >> knowledge of the inner workings of the FPGA, and the simulation would >> be an analog circuits problem. So I suspect that you couldn't do it >> for any specific part unless you worked at the company in question. >> >> -- >> 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 & >> Softwarehttp://www.wescottdesign.com > > That's what probability is all about, dealing with the lack of > knowledge. You don't know the exact voltage of the input when the clock > edge changed and you don't know how fast either signal was changing... > etc. But you do know how often you expect all of these events to line > up to produce metastability and you know the distribution of delay is a > logarithmic taper. > > I won't try to argue about how many angels can dance on the head of a > pin, but I have no information to show me that the formula that Peter > used is not accurate, even for extreme cases. Well, first, I wasn't trying to contradict you -- I just picked the wrong place in the thread to answer Hal's question. And second, before you can know the necessary inputs to your statistical calculations, you need to do some simulating to see how long it takes for the state to come down from various places on the mountaintop. The difference between a circuit that has a narrow & sharp potential peak vs. one that has a wide, flat, broad one is significant. (One that had a true stable spot at 1/2 voltage would be mucho worse, but that's not too likely in this day and age). -- 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: 154002
Tim Wescott <tim@seemywebsite.com> wrote: (snip, someone wrote) >> That's what probability is all about, dealing with the lack of >> knowledge. You don't know the exact voltage of the input when the clock >> edge changed and you don't know how fast either signal was changing... >> etc. But you do know how often you expect all of these events to line >> up to produce metastability and you know the distribution of delay is a >> logarithmic taper. (snip) > Well, first, I wasn't trying to contradict you -- I just picked the wrong > place in the thread to answer Hal's question. > And second, before you can know the necessary inputs to your statistical > calculations, you need to do some simulating to see how long it takes for > the state to come down from various places on the mountaintop. > The difference between a circuit that has a narrow & sharp potential peak > vs. one that has a wide, flat, broad one is significant. Story I heard some years ago, the sharper and narrower the peak, the harder it is to get into the metastable state, but the longer it stays when it actually gets there. -- glenArticle: 154003
On Tue, 10 Jul 2012 04:12:21 +0000, glen herrmannsfeldt wrote: > Tim Wescott <tim@seemywebsite.com> wrote: > > (snip, someone wrote) >>> That's what probability is all about, dealing with the lack of >>> knowledge. You don't know the exact voltage of the input when the >>> clock edge changed and you don't know how fast either signal was >>> changing... etc. But you do know how often you expect all of these >>> events to line up to produce metastability and you know the >>> distribution of delay is a logarithmic taper. > > > (snip) >> Well, first, I wasn't trying to contradict you -- I just picked the >> wrong place in the thread to answer Hal's question. > >> And second, before you can know the necessary inputs to your >> statistical calculations, you need to do some simulating to see how >> long it takes for the state to come down from various places on the >> mountaintop. > >> The difference between a circuit that has a narrow & sharp potential >> peak vs. one that has a wide, flat, broad one is significant. > > Story I heard some years ago, the sharper and narrower the peak, > the harder it is to get into the metastable state, but the longer it > stays when it actually gets there. Wow. That's counter-intuitive. I would think that the sharper the peak the less likely that the device would be stuck without knowing which way to fall. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.comArticle: 154004
Hi, Due to broken design of the FPGA board, I have the master clock available only at MGTREFCLK1P/MGTREFCLK1N pins. Is it possible to use those pins to produce clock for use logic in FPGA instead of GTP transceiver? If I try to connect those pins to the differential input buffer, I get the following errors: Mapping design into LUTs... Running directed packing... ERROR:Pack:1107 - Pack was unable to combine the symbols listed below into a single IOB component because the site type selected is not compatible. Further explanation: The component type is determined by the types of logic and the properties and configuration of the logic it contains. In this case an IO component of type IOB was chosen because the IO contains symbols and/or properties consistent with input, output, or bi-directional usage and contains no other symbols or properties that require a more specific IO component type. Please double check that the types of logic elements and all of their relevant properties and configuration options are compatible with the physical site type of the constraint. Summary: Symbols involved: PAD symbol "gtc_n5" (Pad Signal = gtc_n5) SlaveBuffer symbol "ib1/SLAVEBUF.DIFFIN" (Output Signal = ib1/SLAVEBUF.DIFFIN) Component type involved: IOB Site Location involved: AK19 Site Type involved: IPAD ERROR:Pack:1107 - Pack was unable to combine the symbols listed below into a single IOB component because the site type selected is not compatible. Further explanation: The component type is determined by the types of logic and the properties and configuration of the logic it contains. In this case an IO component of type IOB was chosen because the IO contains symbols and/or properties consistent with input, output, or bi-directional usage and contains no other symbols or properties that require a more specific IO component type. Please double check that the types of logic elements and all of their relevant properties and configuration options are compatible with the physical site type of the constraint. Summary: Symbols involved: PAD symbol "gtc_p5" (Pad Signal = gtc_p5) DIFFAMP symbol "ib1/IBUFDS" (Output Signal = io_clk) Component type involved: IOB Site Location involved: AJ19 Site Type involved: IPAD Is there any component (BUFIO2, or something similar) able to produce normal clock from those pins? -- TIA & Regards, WZabArticle: 154005
Tim Wescott <tim@seemywebsite.please> wrote: (snip, I wrote) >> Story I heard some years ago, the sharper and narrower the peak, >> the harder it is to get into the metastable state, but the longer it >> stays when it actually gets there. > Wow. That's counter-intuitive. I would think that the sharper the peak > the less likely that the device would be stuck without knowing which way > to fall. First, remember that it is conditional on actually getting it to the metastable state. I don't know if it is convincing or not, but consider balancing a knife on its edge on a table. You have a sharp and dull knife. Once you get the sharp knife balanced, it will make a deeper impression into the table and so stay up longer. For the actual physics, there are some symmetries that require some correlations in the probability of getting into, and getting out of, a certain state. If you get it wrong, then energy conservation fails. There is an old favorite, of putting a dark and light colored object in a mirrored room. (Consider an ellipoidal mirror with two spheres at the foci.) Now, consider the effect of black body radiation with a black and a white sphere. The black sphere absorbs most radiation (mostly IR light) but the white one doesn't absorb as much. Conservation of energy requires that the black one emit more black body radiation (that is where the name comes from). If not, the black one would get warmer, and you could extract energy from the temperature difference. Note that this is why heat sinks are (usually) black. (To get a connection to DSP.) Warm objects have more electrons in higher (metastable) states. -- glenArticle: 154006
I am trying to implement a 10G MAC/XAUI design on a Virtex 5 FX200T FPGA. I have tested the same design on a V5 LX100T FPGA successfully and have now generated appropriate MAC/XAUI cores for the the FX200T FPGA. The issue I am seeing now is that data is being sent out of the MAC into the XAUI block, but the XAUI core does not seem to be sending data over a CX4 cable connected to another identical board. - Using XAUI v10.1, ISE 14.1 - Hitech Global HTG-V5-PCIE-200-2 development board with a CX4 adapter - Using GTX tiles 116 and 120 - Fowarding reference clock from GTX 124 (powered down) to GTX 116 and 120 - Able to confirm the following on chipscope: align_status = '1', sync_status = "1111", mgt_tx_ready = '1', mgt_rxlock = '1', and all clocks in the design are active I have used iBERT to check the transcievers and see no bit errors in near-end PCS and PMA loopback modes. However, when the loopback mode is set to none on one card and set to far-end PMA/PCS on another card, there are continuous bit-errors. The link remains high throughout. I am not sure if there are any settings in the transceiver that I need to modify. Appreciate any help. Thanks!Article: 154007
rickman wrote: > Regardless, all I am saying is that you don't need to use a path that > has no logic to obtain *enough* slack to give enough settling time to > the metastable input. Well, one thing that I learned on this group is that metastability is not the most likely problem, it is time skew. If an unsynchronized input is fed to a number of LUTs scattered around the chip, it can have several ns of skew between them. The clocks have tightly controlled skew, so the unsynched input can be sensed differently at two locations. I ran into this on a state machine and it caused the state logic to go to undefined states. This was finally explained, I think by one of the guys at Xilinx, and that it can have a thousand times higher probability than true metastability of a single FF. JonArticle: 154008
In article <af2d18b0-beec-47ac-afd9-49c024034fdd@googlegroups.com>, <wzab01@gmail.com> wrote: >Hi, > >Due to broken design of the FPGA board, I have the master clock available only at MGTREFCLK1P/MGTREFCLK1N pins. >Is it possible to use those pins to produce clock for use logic in FPGA instead of GTP transceiver? > >If I try to connect those pins to the differential input buffer, I get the following errors: > <snip error log> > >Is there any component (BUFIO2, or something similar) able to produce normal clock from those pins? I think the clock must still go through the GTPA1_DUAL. Then use the output pin "GTPCLKOUT[0|1]", connect that to a BUFIO2, then connect the output of the BUFIO2 to a BUFG. I know we've done similar with a virtex6 GTX, and we put the above hooks in place for the Spartan6 versions of our boards. I just don't know if we tested it. It's a good place to start. In any case I'm fairly sure you have to go through the GTP in some form - you can't just tap the clocks directly. In any event, pour over the clocking section of the GTP user's guide. It should give you what you need. Regards, MarkArticle: 154009
On Jul 9, 9:47=A0pm, Tim Wescott <t...@seemywebsite.com> wrote: > On Mon, 09 Jul 2012 17:20:26 -0700, rickman wrote: > > On Jul 9, 2:35=A0pm, Tim Wescott <t...@seemywebsite.com> wrote: > >> On Sun, 08 Jul 2012 15:38:45 -0700, rickman wrote: > >> > On Jul 6, 10:00 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal > >> > Murray) wrote: > >> >> In article <nZ-dnch1rrNvHG_SnZ2dnUVZ_qSdn...@web-ster.com>, > >> >> =A0Tim Wescott <t...@seemywebsite.please> writes: > > >> >> >Paranoid logic designers will have a string of two or three > >> >> >registers to avoid metastability, but I've been told that's not > >> >> >necessary. =A0(I'm not much of a logic designer). > > >> >> Ahh, but are they paranoid enough? > > >> >> The key is settling time. > > >> >> In the old days of TTL chips, a pair of FFs (with no logic in > >> >> between) got you settling time of as much logic as the worst case > >> >> delay for the rest of the system. =A0In practice, that was enough. > > >> >> With FPGAs, routhing is important. =A0A pair of FFs close together = is > >> >> probably good enough. =A0If you put them on opposite sides of a big > >> >> chip, the routing delays may match the long path of the logic delay= s > >> >> and eat up all of your slack time. > > >> >> Have any FPGA vendors published recent metastability info? (Many > >> >> thanks to Peter Alfke for all his good work in this area.) > > >> >> I'm not a silicon wizard. =A0Is it reasonable to simulate this stuf= f? > >> >> I'd like to know worst case rather than typicals. =A0It should be > >> >> possible to do something like verify simulations with lab typicals > >> >> and then use simulations to find the numbers for the nasty corners. > > >> > I'm not sure what you would want to simulate. =A0Metastability is > >> > probabilistic. =A0There is For a given length of settling time there= is > >> > some probability of it happening. =A0Increasing the settling time > >> > reduces the probability but it will never be zero meaning there is n= o > >> > max length of time it takes for the output of a metastable ff to > >> > settle. > > >> The drivers of metastability are probabilistic, yes. =A0But given enou= gh > >> information you could certainly simulate the positive feedback loop > >> that is a flip-flop. > > >> I suspect that unless the ball that is the flip-flop state is poised > >> right on the top of the mountain between the Valley of Zero and the > >> Valley of One, that the problem is mostly deterministic. =A0It's only > >> when the after-strobe balance is perfect and the gain is so low that > >> the FF voltage is affected more by noise than by actual circuit forces > >> that the problem would remain probabilistic _after_ the strobe > >> happened. > > >> "Enough information", in this case, would involve a whole lot of deep > >> knowledge of the inner workings of the FPGA, and the simulation would > >> be an analog circuits problem. =A0So I suspect that you couldn't do it > >> for any specific part unless you worked at the company in question. > > >> -- > >> 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 & > >> Softwarehttp://www.wescottdesign.com > > > That's what probability is all about, dealing with the lack of > > knowledge. =A0You don't know the exact voltage of the input when the cl= ock > > edge changed and you don't know how fast either signal was changing... > > etc. =A0But you do know how often you expect all of these events to lin= e > > up to produce metastability and you know the distribution of delay is a > > logarithmic taper. > > > I won't try to argue about how many angels can dance on the head of a > > pin, but I have no information to show me that the formula that Peter > > used is not accurate, even for extreme cases. > > Well, first, I wasn't trying to contradict you -- I just picked the wrong > place in the thread to answer Hal's question. > > And second, before you can know the necessary inputs to your statistical > calculations, you need to do some simulating to see how long it takes for > the state to come down from various places on the mountaintop. > > The difference between a circuit that has a narrow & sharp potential peak > vs. one that has a wide, flat, broad one is significant. > > (One that had a true stable spot at 1/2 voltage would be mucho worse, but > that's not too likely in this day and age). > > -- > 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 & Softwarehttp://www.wesco= ttdesign.com Sorry if my tone sounded like I was offended at all, I'm not. I was just trying to make the point that you don't know the shape of the "mountain" the ball is balanced on and I doubt a simulation could model it very well. But that is outside my expertise so if I am wrong... But I still fail to see how that shape would affect anything significantly. Unless it has flat spots or even indentations that were local minima, what would the shape change? It would most likely only change the speed at which the ball falls off the "mountain" which is part of what is measured when they characterize a device the way Peter Alfke did. Still, even if there is some abnormalities in the shape of the "mountain", is that really important? The goal is to get the possibility so far out you just don't have to think about it. If the shape changes the probability by a factor of 10 either way it shouldn't make a problem. Just add another 200 ps to the slack and get another order of magnitude in the MTBF. Or was it 100 ps? RickArticle: 154010
On Jul 9, 9:23=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > rickman <gnu...@gmail.com> wrote: > > (snip, I wrote) > > >> I suppose that is true, but really it shouldn't be a problem. > >> It is usual for many systems to clock as fast as you can, > >> consistent with the critical path delay. As metastability > >> is exponential, even a slightly shorter delay is usually enough > >> to make enough difference in the exponent. > >> That assumes that there is a FF to FF path that is faster than > >> the FF logic FF path. I believe that is usual for FPGAs, but > >> if you manage to get a critical path with only one LUT, then > >> I am not so sure. But that is pretty hard in most real systems. > > (snip) > > > You keep talking about the critical path delay as if the metastable > > input is driving the critical path. =A0There is only one critical path > > in a design normally. =A0All other paths are faster. =A0Are you assumin= g > > that all paths have the same amount of delay? > > No, but it might be that many have about the same delay. Well, > my favorite things to design are systolic arrays, where there is > the same logic (though with different routing, different delay) > between a large number of FFs. > > For any pipelined processor, the most efficient logic has about > the same delay between successive registers. We are still not talking about the same thing. The *max* delay in each stage will be roughly even, but within a stage there will be all sorts of delays. If you are balancing all paths to achieve even delays you are working on a very intense design akin to the original Cray computers with hand designed ECL chip logic. > > Regardless, all I am saying is that you don't need to use a path that > > has no logic to obtain *enough* slack to give enough settling time to > > the metastable input. =A0But in all cases you need to verify this. > > Yes. One would hope that no logic would have the shortest delay, > though in the case of FPGAs, you might not be able to count on that. Yes, that is the point, you need to verify the required slack time no mater what is in the path. > > As mentioned in another post, Peter Alfke's numbers show that you only > > need about 2 ns to get 100 million years MTBF. =A0Of course whether thi= s > > is good enough depends on just how reliable your systems have to be > > and how many there are. =A0It is 100 million years for one unit, but fo= r > > 10 million units it will only be 10 years MTBF for the group. > > I have done designs with at most two LUTs between registers, > and might even be able to do one. That would be good, but I don't know if it is very practical. To make that useful you also have to optimize the placement to minimize routing delays. I haven't seen that done since some of Ray Andraka's designs which are actually fairly small by today's standards. I can't conceive of trying that with many current designs. RickArticle: 154011
Hi,
I am not an FPGA expert although this is not my first design. The
problem that I am having for two days now, is that I am observing
different results when simulating a design in GHDL and in Modelsim
ALTERA starter edition.
The design includes a shift register. The significant code is:
read_sro : process(s_sample)
begin
if rising_edge(s_sample) then
if ... --irrelevant here
end if;
if ...
end if;
if sr_burst_ena = '1' then --First phase: store data in shift_reg
new_data <= sr_sro_wave & new_data(c_burst_no-1 downto 1);
elsif dec_shift_ena = '1' then --Second phase: rotate data
new_data <= new_data(0) & new_data(c_burst_no-1 downto 1);
--irrelevant, but included for completeness
max_cnt <= max_cnt + 1;
if usum > max then
max <= usum;
max_pos <= max_cnt;
end if;
end if;
end if;
end process read_sro;
the clock signal s_sample is obtained from the main 50 MHz clock with
the following process:
sr_signals : process(clk)
begin
if rising_edge(clk) then
if sr_clear = '1' or sr_burst_ena = '1' or dec_shift_ena ='1' then
s_sample <= not s_sample;
end if;
...
end if;
end process sr_signals;
I have uploaded some screenshots here:
1- ghdl+gtkwave result http://tinypic.com/r/wklimq/6
2- simulink http://tinypic.com/r/2le743t/6
It may be seen that the input signal (top signal in the GHDL result and
third from the top in SIMULINK) is zero during the first 5 s_sample
clocks, then is at one during 10 clocks and zero again for the rest of
the (up to 20) clocks.
The GHDL simulation shows up ok, with the register correctly loaded with
0000011111111110000 after the 20 clocks, however Altera's quartus gives
00000111110000011111.
Exactly the same file is being fed to to Quartus II for synthesis!! But
Alteras RTL (and gate level) simulations do not behave as intended.
Is there something with the coding style than can make Quartus infer an
absolutely different behaviour? Any help is very much appreciated!!
Pere
Article: 154012
On Wednesday, July 11, 2012 7:23:51 AM UTC-4, o pere o wrote:
> Hi,
>=20
> I am not an FPGA expert although this is not my first design. The=20
> problem that I am having for two days now, is that I am observing=20
> different results when simulating a design in GHDL and in Modelsim=20
> ALTERA starter edition.
>=20
> The design includes a shift register. The significant code is:
>=20
> read_sro : process(s_sample)
> begin
> if rising_edge(s_sample) then
> if ... --irrelevant here
> end if;
> if ... =09
> end if;=09
> if sr_burst_ena =3D '1' then --First phase: store data in=
shift_reg
> new_data <=3D sr_sro_wave & new_data(c_burst_no-1 downt=
o 1);
> elsif dec_shift_ena =3D '1' then --Second phase: rotate d=
ata
>=20
> new_data <=3D new_data(0) & new_data(c_burst_no-1 downt=
o 1);
>=20
> --irrelevant, but included for completeness
> max_cnt <=3D max_cnt + 1;
> if usum > max then
> max <=3D usum;
> max_pos <=3D max_cnt;
> end if;
> end if;
> end if;
> end process read_sro;
>=20
> the clock signal s_sample is obtained from the main 50 MHz clock with=20
> the following process:
>=20
> sr_signals : process(clk)
> begin
> if rising_edge(clk) then
> if sr_clear =3D '1' or sr_burst_ena =3D '1' or dec_=
shift_ena =3D'1' then
> s_sample <=3D not s_sample;
> end if;
> ...
> end if;
> end process sr_signals;
>=20
> I have uploaded some screenshots here:
>=20
> 1- ghdl+gtkwave result http://tinypic.com/r/wklimq/6
> 2- simulink http://tinypic.com/r/2le743t/6
>=20
> It may be seen that the input signal (top signal in the GHDL result and=
=20
> third from the top in SIMULINK) is zero during the first 5 s_sample=20
> clocks, then is at one during 10 clocks and zero again for the rest of=20
> the (up to 20) clocks.
>=20
> The GHDL simulation shows up ok, with the register correctly loaded with=
=20
> 0000011111111110000 after the 20 clocks, however Altera's quartus giv=
es=20
> 00000111110000011111.
>=20
> Exactly the same file is being fed to to Quartus II for synthesis!! But=
=20
> Alteras RTL (and gate level) simulations do not behave as intended.
>=20
> Is there something with the coding style than can make Quartus infer an=
=20
> absolutely different behaviour? Any help is very much appreciated!!
>=20
> Pere
By generating an internal clock signal you're not following synchronous des=
ign practice. In an FPGA design that spells trouble. What you need to do =
to make it synchronous is:
- Change the 'sr_signals' process that currently generates 's_sample'. Wha=
t you'll want is for 's_sample' to be a one clock cycle pulse at the approp=
riate time. Modify your if statement to accomplish this.
- Modify the 'read_src' process to use the free running clock and 's_sample=
' like this
read_sro : process(clk)=20
begin=20
if rising_edge(clk) then
if (s_sample =3D '1') then
-- Put all of the code you have that was previously within
-- the "if rising_edge(s_sample) then" statement here
end if;
end if;
end process read_src;
The reason that generated clocks are bad news in an FPGA is that you have e=
ssentially zero control over signal skew. A signal generated in one clock =
domain can, depending on the routing, make it over into the other clock dom=
ain even before the generated clock gets there, or perhaps after. In your =
case, you really have no way to say what skew there is between 'clk' and 's=
_sample'. The signals 'sr_burst_ena' and 'dec_shift_ena' are used in both =
of your processes and yet each can only be valid in one clock domain (your =
posted code does not show those signal assignments so it is not clear in wh=
ich domain they have been generated, but I suspect it is in 'clk').
Kevin Jennings
Article: 154013On 07/11/2012 02:02 PM, KJ wrote: > On Wednesday, July 11, 2012 7:23:51 AM UTC-4, o pere o wrote: >> Hi, >> >> I am not an FPGA expert although this is not my first design. The >> problem that I am having for two days now, is that I am observing >> different results when simulating a design in GHDL and in Modelsim >> ALTERA starter edition. >> >> The design includes a shift register. The significant code is: >> >> read_sro : process(s_sample) >> begin >> if rising_edge(s_sample) then >> if ... --irrelevant here >> end if; >> if ... >> end if; >> if sr_burst_ena ='1' then --First phase: store data in shift_reg >> new_data<= sr_sro_wave& new_data(c_burst_no-1 downto 1); >> elsif dec_shift_ena ='1' then --Second phase: rotate data >> >> new_data<= new_data(0)& new_data(c_burst_no-1 downto 1); >> >> --irrelevant, but included for completeness >> max_cnt<= max_cnt + 1; >> if usum> max then >> max<= usum; >> max_pos<= max_cnt; >> end if; >> end if; >> end if; >> end process read_sro; >> >> the clock signal s_sample is obtained from the main 50 MHz clock with >> the following process: >> >> sr_signals : process(clk) >> begin >> if rising_edge(clk) then >> if sr_clear ='1' or sr_burst_ena ='1' or dec_shift_ena ='1' then >> s_sample<= not s_sample; >> end if; >> ... >> end if; >> end process sr_signals; >> >> I have uploaded some screenshots here: >> >> 1- ghdl+gtkwave result http://tinypic.com/r/wklimq/6 >> 2- simulink http://tinypic.com/r/2le743t/6 >> >> It may be seen that the input signal (top signal in the GHDL result and >> third from the top in SIMULINK) is zero during the first 5 s_sample >> clocks, then is at one during 10 clocks and zero again for the rest of >> the (up to 20) clocks. >> >> The GHDL simulation shows up ok, with the register correctly loaded with >> 0000011111111110000 after the 20 clocks, however Altera's quartus gives >> 00000111110000011111. >> >> Exactly the same file is being fed to to Quartus II for synthesis!! But >> Alteras RTL (and gate level) simulations do not behave as intended. >> >> Is there something with the coding style than can make Quartus infer an >> absolutely different behaviour? Any help is very much appreciated!! >> >> Pere > > By generating an internal clock signal you're not following synchronous design practice. In an FPGA design that spells trouble. What you need to do to make it synchronous is: > > - Change the 'sr_signals' process that currently generates 's_sample'. What you'll want is for 's_sample' to be a one clock cycle pulse at the appropriate time. Modify your if statement to accomplish this. > - Modify the 'read_src' process to use the free running clock and 's_sample' like this > > read_sro : process(clk) > begin > if rising_edge(clk) then > if (s_sample = '1') then > -- Put all of the code you have that was previously within > -- the "if rising_edge(s_sample) then" statement here > end if; > end if; > end process read_src; > > The reason that generated clocks are bad news in an FPGA is that you have essentially zero control over signal skew. A signal generated in one clock domain can, depending on the routing, make it over into the other clock domain even before the generated clock gets there, or perhaps after. In your case, you really have no way to say what skew there is between 'clk' and 's_sample'. The signals 'sr_burst_ena' and 'dec_shift_ena' are used in both of your processes and yet each can only be valid in one clock domain (your posted code does not show those signal assignments so it is not clear in which domain they have been generated, but I suspect it is in 'clk'). > > Kevin Jennings > Kevin Thanks for your input! I know that this does not result in a synchronous design, and I was already thinking of rewriting it with clock enables, as you suggested. However, this was done because, in this case, there is no signal generated in the "clk" domain that is read by "s_sample". Actually "s_sample" is only used to read some signals from the outside world and the shift register more or less tries to correlate what is read in the present cycle with the previous ones. Is it correct to say that, in this case, "it doesn't matter"? Now, completely agreeing with your observation, I am still puzzled by the fact that the even the RTL simulation (which I assume does not take any delays into account) is not working properly. If you have a look at the simulation results, this is absolutely not a shift register! It seems that Altera's synthesis tool infers something quite different... but why?? PereArticle: 154014
o pere o <me@somewhere.net> wrote: > I am not an FPGA expert although this is not my first design. The > problem that I am having for two days now, is that I am observing > different results when simulating a design in GHDL and in Modelsim > ALTERA starter edition. (snip) > the clock signal s_sample is obtained from the main 50 MHz > clock with the following process: > sr_signals : process(clk) > begin > if rising_edge(clk) then > if sr_clear = '1' or sr_burst_ena = '1' or dec_shift_ena ='1' then > s_sample <= not s_sample; > end if; > ... > end if; > end process sr_signals; You don't show where dec_shift_ena comes from. (snip) > The GHDL simulation shows up ok, with the register correctly loaded with > 0000011111111110000 after the 20 clocks, however Altera's quartus gives > 00000111110000011111. > Exactly the same file is being fed to to Quartus II for synthesis!! But > Alteras RTL (and gate level) simulations do not behave as intended. > Is there something with the coding style than can make Quartus infer an > absolutely different behaviour? Any help is very much appreciated!! There are designs where the HDL code can simulate differently from the usual synthesis. In that case, one could expect differences from different simulators. Unless you are doing post-route simulation, there are no delays in use, but some signals are known to come after others. The output of a FF will change after, never at the same time, as the input. You can't make any assumption, though, on the outputs of two FFs with the same clock input. In simulation, one may be considered before or after the other. In actual logic, with actual wire delays, the result can be a race condition, where the result is uncertain. I didn't see in the logic where that happened, but maybe in the part that wasn't shown. Especially dec_shift_ena. -- glenArticle: 154015
On Jul 11, 12:48 pm, o pere o <m...@somewhere.net> wrote: > On 07/11/2012 02:02 PM, KJ wrote: > > > > > > > > > On Wednesday, July 11, 2012 7:23:51 AM UTC-4, o pere o wrote: > >> Hi, > > >> I am not an FPGA expert although this is not my first design. The > >> problem that I am having for two days now, is that I am observing > >> different results when simulating a design in GHDL and in Modelsim > >> ALTERA starter edition. > > >> The design includes a shift register. The significant code is: > > >> read_sro : process(s_sample) > >> begin > >> if rising_edge(s_sample) then > >> if ... --irrelevant here > >> end if; > >> if ... > >> end if; > >> if sr_burst_ena =3D'1' then --First phase: store data= in shift_reg > >> new_data<=3D sr_sro_wave& new_data(c_burst_no-1 dow= nto 1); > >> elsif dec_shift_ena =3D'1' then --Second phase: rotat= e data > > >> new_data<=3D new_data(0)& new_data(c_burst_no-1 dow= nto 1); > > >> --irrelevant, but included for completeness > >> max_cnt<=3D max_cnt + 1; > >> if usum> max then > >> max<=3D usum; > >> max_pos<=3D max_cnt; > >> end if; > >> end if; > >> end if; > >> end process read_sro; > > >> the clock signal s_sample is obtained from the main 50 MHz clock with > >> the following process: > > >> sr_signals : process(clk) > >> begin > >> if rising_edge(clk) then > >> if sr_clear =3D'1' or sr_burst_ena =3D'1' or de= c_shift_ena =3D'1' then > >> s_sample<=3D not s_sample; > >> end if; > >> ... > >> end if; > >> end process sr_signals; > > >> I have uploaded some screenshots here: > > >> 1- ghdl+gtkwave resulthttp://tinypic.com/r/wklimq/6 > >> 2- simulinkhttp://tinypic.com/r/2le743t/6 > > >> It may be seen that the input signal (top signal in the GHDL result an= d > >> third from the top in SIMULINK) is zero during the first 5 s_sample > >> clocks, then is at one during 10 clocks and zero again for the rest of > >> the (up to 20) clocks. > > >> The GHDL simulation shows up ok, with the register correctly loaded wi= th > >> 0000011111111110000 after the 20 clocks, however Altera's quartus = gives > >> 00000111110000011111. > > >> Exactly the same file is being fed to to Quartus II for synthesis!! Bu= t > >> Alteras RTL (and gate level) simulations do not behave as intended. > > >> Is there something with the coding style than can make Quartus infer a= n > >> absolutely different behaviour? Any help is very much appreciated!! > > >> Pere > > > By generating an internal clock signal you're not following synchronous= design practice. In an FPGA design that spells trouble. What you need to= do to make it synchronous is: > > > - Change the 'sr_signals' process that currently generates 's_sample'. = What you'll want is for 's_sample' to be a one clock cycle pulse at the ap= propriate time. Modify your if statement to accomplish this. > > - Modify the 'read_src' process to use the free running clock and 's_sa= mple' like this > > > read_sro : process(clk) > > begin > > if rising_edge(clk) then > > if (s_sample =3D '1') then > > -- Put all of the code you have that was previously within > > -- the "if rising_edge(s_sample) then" statement here > > end if; > > end if; > > end process read_src; > > > The reason that generated clocks are bad news in an FPGA is that you ha= ve essentially zero control over signal skew. A signal generated in one cl= ock domain can, depending on the routing, make it over into the other clock= domain even before the generated clock gets there, or perhaps after. In y= our case, you really have no way to say what skew there is between 'clk' an= d 's_sample'. The signals 'sr_burst_ena' and 'dec_shift_ena' are used in b= oth of your processes and yet each can only be valid in one clock domain (y= our posted code does not show those signal assignments so it is not clear i= n which domain they have been generated, but I suspect it is in 'clk'). > > > Kevin Jennings > > Kevin > > Thanks for your input! > > I know that this does not result in a synchronous design, and I was > already thinking of rewriting it with clock enables, as you suggested. > > However, this was done because, in this case, there is no signal > generated in the "clk" domain that is read by "s_sample". Actually > "s_sample" is only used to read some signals from the outside world and > the shift register more or less tries to correlate what is read in the > present cycle with the previous ones. > > Is it correct to say that, in this case, "it doesn't matter"? > > Now, completely agreeing with your observation, I am still puzzled by > the fact that the even the RTL simulation (which I assume does not take > any delays into account) is not working properly. If you have a look at > the simulation results, this is absolutely not a shift register! > > It seems that Altera's synthesis tool infers something quite > different... but why?? > > Pere Your design is synchronous, but you have more than one clock, so you need to be sure of the timing of signals that cross the clock domains. For example, the signals sr_clear, sr_burst_ena and dec_shift_ena seem to be used in both the clk and the s_sample clock domains without being synchonized. I guess that might be ok if you can make sure the delays in the s_sample clock don't result in one of these signals changing on the edge of either clock. If the simulation is not what you want, then there is likely something wrong with the code. But remember that while the simulation does not account for logic delays, there are delta delays that mean signals clocked by clk will have already changed by the time the remaining code sees the change in s_sample. RickArticle: 154016
On 07/11/2012 08:53 PM, glen herrmannsfeldt wrote:
> o pere o<me@somewhere.net> wrote:
>
>> I am not an FPGA expert although this is not my first design. The
>> problem that I am having for two days now, is that I am observing
>> different results when simulating a design in GHDL and in Modelsim
>> ALTERA starter edition.
>
> (snip)
>
>> the clock signal s_sample is obtained from the main 50 MHz
>> clock with the following process:
>
>> sr_signals : process(clk)
>> begin
>> if rising_edge(clk) then
>> if sr_clear = '1' or sr_burst_ena = '1' or dec_shift_ena ='1' then
>> s_sample<= not s_sample;
>> end if;
>> ...
>> end if;
>> end process sr_signals;
>
> You don't show where dec_shift_ena comes from.
Sorry for the omission!
dec_shift_ena is generated as follows. First, I have a counter the is
reset periodically:
clock_counter: process(clk) --counter counting over the symbol length
begin
if rising_edge(clk) then
if tc_symbol = '1' then
clk_count <= 0;
else
clk_count <= clk_count + 1;
end if;
end if;
end process clock_counter;
tc_symbol <= '1' when clk_count=c_ticks_per_symbol-1 else '0';
From this counter, I also generate some time markers, such as
dec_shift_ena_pre <= '1' when (clk_count >= ...) and (...)
else '0';
which are resynchronized in
process(clk)
begin
if rising_edge(clk) then
...
dec_shift_ena <= dec_shift_ena_pre;
end if;
end process;
> (snip)
>
>> The GHDL simulation shows up ok, with the register correctly loaded with
>> 0000011111111110000 after the 20 clocks, however Altera's quartus gives
>> 00000111110000011111.
>
>> Exactly the same file is being fed to to Quartus II for synthesis!! But
>> Alteras RTL (and gate level) simulations do not behave as intended.
>
>> Is there something with the coding style than can make Quartus infer an
>> absolutely different behaviour? Any help is very much appreciated!!
>
> There are designs where the HDL code can simulate differently from
> the usual synthesis. In that case, one could expect differences
> from different simulators.
>
> Unless you are doing post-route simulation, there are no delays
> in use, but some signals are known to come after others.
>
> The output of a FF will change after, never at the same time, as
> the input.
>
> You can't make any assumption, though, on the outputs of two FFs
> with the same clock input. In simulation, one may be considered
> before or after the other. In actual logic, with actual wire
> delays, the result can be a race condition, where the result
> is uncertain.
>
> I didn't see in the logic where that happened, but maybe in
> the part that wasn't shown. Especially dec_shift_ena.
>
> -- glen
>
I get the same results with RTL and with post-route simulation (except
for minor delays, as expected). I guess Altera's synthesis tool is doing
something strange at exactly the half of the shif register new_data: The
top half shifts correctly, but the bottom half looks as if it was
inverted. I can't figure out how a timing issue could have this outcome,
but I am probably missing something obvious -and hopefully someone can
point this out :) !!
Pere
Article: 154017On 07/11/2012 10:13 PM, rickman wrote: > On Jul 11, 12:48 pm, o pere o<m...@somewhere.net> wrote: >> On 07/11/2012 02:02 PM, KJ wrote: >> >> >> >> >> >> >> >>> On Wednesday, July 11, 2012 7:23:51 AM UTC-4, o pere o wrote: >>>> Hi, >> >>>> I am not an FPGA expert although this is not my first design. The >>>> problem that I am having for two days now, is that I am observing >>>> different results when simulating a design in GHDL and in Modelsim >>>> ALTERA starter edition. >> >>>> The design includes a shift register. The significant code is: >> >>>> read_sro : process(s_sample) >>>> begin >>>> if rising_edge(s_sample) then >>>> if ... --irrelevant here >>>> end if; >>>> if ... >>>> end if; >>>> if sr_burst_ena ='1' then --First phase: store data in shift_reg >>>> new_data<= sr_sro_wave& new_data(c_burst_no-1 downto 1); >>>> elsif dec_shift_ena ='1' then --Second phase: rotate data >> >>>> new_data<= new_data(0)& new_data(c_burst_no-1 downto 1); >> >>>> --irrelevant, but included for completeness >>>> max_cnt<= max_cnt + 1; >>>> if usum> max then >>>> max<= usum; >>>> max_pos<= max_cnt; >>>> end if; >>>> end if; >>>> end if; >>>> end process read_sro; >> >>>> the clock signal s_sample is obtained from the main 50 MHz clock with >>>> the following process: >> >>>> sr_signals : process(clk) >>>> begin >>>> if rising_edge(clk) then >>>> if sr_clear ='1' or sr_burst_ena ='1' or dec_shift_ena ='1' then >>>> s_sample<= not s_sample; >>>> end if; >>>> ... >>>> end if; >>>> end process sr_signals; >> >>>> I have uploaded some screenshots here: >> >>>> 1- ghdl+gtkwave resulthttp://tinypic.com/r/wklimq/6 >>>> 2- simulinkhttp://tinypic.com/r/2le743t/6 >> >>>> It may be seen that the input signal (top signal in the GHDL result and >>>> third from the top in SIMULINK) is zero during the first 5 s_sample >>>> clocks, then is at one during 10 clocks and zero again for the rest of >>>> the (up to 20) clocks. >> >>>> The GHDL simulation shows up ok, with the register correctly loaded with >>>> 0000011111111110000 after the 20 clocks, however Altera's quartus gives >>>> 00000111110000011111. >> >>>> Exactly the same file is being fed to to Quartus II for synthesis!! But >>>> Alteras RTL (and gate level) simulations do not behave as intended. >> >>>> Is there something with the coding style than can make Quartus infer an >>>> absolutely different behaviour? Any help is very much appreciated!! >> >>>> Pere >> >>> By generating an internal clock signal you're not following synchronous design practice. In an FPGA design that spells trouble. What you need to do to make it synchronous is: >> >>> - Change the 'sr_signals' process that currently generates 's_sample'. What you'll want is for 's_sample' to be a one clock cycle pulse at the appropriate time. Modify your if statement to accomplish this. >>> - Modify the 'read_src' process to use the free running clock and 's_sample' like this >> >>> read_sro : process(clk) >>> begin >>> if rising_edge(clk) then >>> if (s_sample = '1') then >>> -- Put all of the code you have that was previously within >>> -- the "if rising_edge(s_sample) then" statement here >>> end if; >>> end if; >>> end process read_src; >> >>> The reason that generated clocks are bad news in an FPGA is that you have essentially zero control over signal skew. A signal generated in one clock domain can, depending on the routing, make it over into the other clock domain even before the generated clock gets there, or perhaps after. In your case, you really have no way to say what skew there is between 'clk' and 's_sample'. The signals 'sr_burst_ena' and 'dec_shift_ena' are used in both of your processes and yet each can only be valid in one clock domain (your posted code does not show those signal assignments so it is not clear in which domain they have been generated, but I suspect it is in 'clk'). >> >>> Kevin Jennings >> >> Kevin >> >> Thanks for your input! >> >> I know that this does not result in a synchronous design, and I was >> already thinking of rewriting it with clock enables, as you suggested. >> >> However, this was done because, in this case, there is no signal >> generated in the "clk" domain that is read by "s_sample". Actually >> "s_sample" is only used to read some signals from the outside world and >> the shift register more or less tries to correlate what is read in the >> present cycle with the previous ones. >> >> Is it correct to say that, in this case, "it doesn't matter"? >> >> Now, completely agreeing with your observation, I am still puzzled by >> the fact that the even the RTL simulation (which I assume does not take >> any delays into account) is not working properly. If you have a look at >> the simulation results, this is absolutely not a shift register! >> >> It seems that Altera's synthesis tool infers something quite >> different... but why?? >> >> Pere > > Your design is synchronous, but you have more than one clock, so you > need to be sure of the timing of signals that cross the clock > domains. For example, the signals sr_clear, sr_burst_ena and > dec_shift_ena seem to be used in both the clk and the s_sample clock > domains without being synchonized. I guess that might be ok if you > can make sure the delays in the s_sample clock don't result in one of > these signals changing on the edge of either clock. > > If the simulation is not what you want, then there is likely something > wrong with the code. But remember that while the simulation does not > account for logic delays, there are delta delays that mean signals > clocked by clk will have already changed by the time the remaining > code sees the change in s_sample. > > Rick Hi, Rick the signals you are mentioning are being updated in the same process(clk) that creates s_sample. They are only read in the process(s_sample) as shown. However, there are no timing issues with this showing up in the post-route simulation (in hindsight, perhaps I was too lucky with this). Otoh, the main point is that one simulation does what I want (and corresponds with the intended behaviour: the GHDL result) but the other one does not! GHDL simulates the semantics of VHDL, and Simulink simulates what Quartus' synthesis has inferred -which does not seem to be the same! Pere PereArticle: 154018
o pere o <me@somewhere.net> wrote: (snip, I wrote) >> You don't show where dec_shift_ena comes from. > Sorry for the omission! > dec_shift_ena is generated as follows. > First, I have a counter the is reset periodically: > clock_counter: process(clk) --counter counting over the symbol length > begin > if rising_edge(clk) then > if tc_symbol = '1' then > clk_count <= 0; > else > clk_count <= clk_count + 1; > end if; > end if; > end process clock_counter; > tc_symbol <= '1' when clk_count=c_ticks_per_symbol-1 else '0'; > From this counter, I also generate some time markers, such as > dec_shift_ena_pre <= '1' when (clk_count >= ...) and (...) > else '0'; > which are resynchronized in I read verilog much better, but this sounds suspicious. Why does it need resynchronizing? > process(clk) > begin > if rising_edge(clk) then > ... > dec_shift_ena <= dec_shift_ena_pre; > end if; > end process; -- glenArticle: 154019
On 07/12/2012 02:55 PM, glen herrmannsfeldt wrote: > o pere o<me@somewhere.net> wrote: > > (snip, I wrote) >>> You don't show where dec_shift_ena comes from. > >> Sorry for the omission! > >> dec_shift_ena is generated as follows. >> First, I have a counter the is reset periodically: > >> clock_counter: process(clk) --counter counting over the symbol length >> begin >> if rising_edge(clk) then >> if tc_symbol = '1' then >> clk_count<= 0; >> else >> clk_count<= clk_count + 1; >> end if; >> end if; >> end process clock_counter; >> tc_symbol<= '1' when clk_count=c_ticks_per_symbol-1 else '0'; > >> From this counter, I also generate some time markers, such as > >> dec_shift_ena_pre<= '1' when (clk_count>= ...) and (...) >> else '0'; > >> which are resynchronized in > > I read verilog much better, but this sounds suspicious. > Why does it need resynchronizing? Being a combinational assignment, it is subject to glitches. The instants where they happen seemed to upset the post-route simulation, with complaints of hold time to short (iirc). BTW, the timing analyser did not complain at all. Making them a registered signal (and pre-compensating the one-cycle delay) cleared glitches and moved the transitions so that simulation goes ok. Pere > >> process(clk) >> begin >> if rising_edge(clk) then >> ... >> dec_shift_ena<= dec_shift_ena_pre; >> end if; >> end process; > > -- glenArticle: 154020
On Jul 12, 3:35=A0am, o pere o <m...@somewhere.net> wrote: > On 07/11/2012 10:13 PM, rickman wrote: > > > > > > > > > > > On Jul 11, 12:48 pm, o pere o<m...@somewhere.net> =A0wrote: > >> On 07/11/2012 02:02 PM, KJ wrote: > > >>> On Wednesday, July 11, 2012 7:23:51 AM UTC-4, o pere o wrote: > >>>> Hi, > > >>>> I am not an FPGA expert although this is not my first design. The > >>>> problem that I am having for two days now, is that I am observing > >>>> different results when simulating a design in GHDL and in Modelsim > >>>> ALTERA starter edition. > > >>>> The design includes a shift register. The significant code is: > > >>>> =A0 =A0 =A0read_sro : process(s_sample) > >>>> =A0 =A0 =A0begin > >>>> =A0 =A0 =A0 =A0if rising_edge(s_sample) then > >>>> =A0 =A0 =A0 =A0 =A0if ... --irrelevant here > >>>> =A0 =A0 =A0 =A0 =A0end if; > >>>> =A0 =A0 =A0 =A0 =A0if ... > >>>> =A0 =A0 =A0 =A0 =A0end if; > >>>> =A0 =A0 =A0 =A0 =A0if sr_burst_ena =3D'1' then =A0--First ph= ase: store data in shift_reg > >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0new_data<=3D sr_sro_wave& new_data= (c_burst_no-1 downto 1); > >>>> =A0 =A0 =A0 =A0 =A0 elsif dec_shift_ena =3D'1' then --Second= phase: rotate data > > >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0new_data<=3D new_data(0)& new_data= (c_burst_no-1 downto 1); > > >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0--irrelevant, but included for completene= ss > >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0max_cnt<=3D max_cnt + 1; > >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0if usum> max then > >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 max<=3D usum; > >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 max_pos<=3D max_cnt; > >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0end if; > >>>> =A0 =A0 =A0 =A0 =A0 end if; > >>>> =A0 =A0 =A0 =A0end if; > >>>> =A0 =A0 =A0end process read_sro; > > >>>> the clock signal s_sample is obtained from the main 50 MHz clock wit= h > >>>> the following process: > > >>>> sr_signals : process(clk) > >>>> begin > >>>> =A0 =A0 =A0 if rising_edge(clk) then > >>>> =A0 =A0 =A0 =A0 if sr_clear =3D'1' or sr_burst_ena =3D'1= ' or dec_shift_ena =3D'1' then > >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0s_sample<=3D not s_sample; > >>>> =A0 =A0 =A0 =A0 end if; > >>>> =A0 =A0 =A0 ... > >>>> =A0 =A0 =A0 end if; > >>>> end process sr_signals; > > >>>> I have uploaded some screenshots here: > > >>>> 1- ghdl+gtkwave resulthttp://tinypic.com/r/wklimq/6 > >>>> 2- simulinkhttp://tinypic.com/r/2le743t/6 > > >>>> It may be seen that the input signal (top signal in the GHDL result = and > >>>> third from the top in SIMULINK) is zero during the first 5 s_sample > >>>> clocks, then is at one during 10 clocks and zero again for the rest = of > >>>> the (up to 20) clocks. > > >>>> The GHDL simulation shows up ok, with the register correctly loaded = with > >>>> 0000011111111110000 after the 20 clocks, however Altera's quartu= s gives > >>>> 00000111110000011111. > > >>>> Exactly the same file is being fed to to Quartus II for synthesis!! = But > >>>> Alteras RTL (and gate level) simulations do not behave as intended. > > >>>> Is there something with the coding style than can make Quartus infer= an > >>>> absolutely different behaviour? Any help is very much appreciated!! > > >>>> Pere > > >>> By generating an internal clock signal you're not following synchrono= us design practice. =A0In an FPGA design that spells trouble. =A0What you n= eed to do to make it synchronous is: > > >>> - Change the 'sr_signals' process that currently generates 's_sample'= . =A0What you'll want is for 's_sample' to be a one clock cycle pulse at th= e appropriate time. =A0Modify your if statement to accomplish this. > >>> - Modify the 'read_src' process to use the free running clock and 's_= sample' like this > > >>> read_sro : process(clk) > >>> begin > >>> =A0 =A0 =A0 if rising_edge(clk) then > >>> =A0 =A0 =A0 =A0 =A0if (s_sample =3D '1') then > >>> =A0 =A0 =A0 =A0 =A0 =A0 -- Put all of the code you have that was prev= iously within > >>> =A0 =A0 =A0 =A0 =A0 =A0 -- the "if rising_edge(s_sample) then" statem= ent here > >>> =A0 =A0 =A0 =A0 =A0end if; > >>> =A0 =A0 =A0 end if; > >>> end process read_src; > > >>> The reason that generated clocks are bad news in an FPGA is that you = have essentially zero control over signal skew. =A0A signal generated in on= e clock domain can, depending on the routing, make it over into the other c= lock domain even before the generated clock gets there, or perhaps after. = =A0In your case, you really have no way to say what skew there is between '= clk' and 's_sample'. =A0The signals 'sr_burst_ena' and 'dec_shift_ena' are = used in both of your processes and yet each can only be valid in one clock = domain (your posted code does not show those signal assignments so it is no= t clear in which domain they have been generated, but I suspect it is in 'c= lk'). > > >>> Kevin Jennings > > >> Kevin > > >> Thanks for your input! > > >> I know that this does not result in a synchronous design, and I was > >> already thinking of rewriting it with clock enables, as you suggested. > > >> However, this was done because, in this case, there is no signal > >> generated in the "clk" domain that is read by "s_sample". Actually > >> "s_sample" is only used to read some signals from the outside world an= d > >> the shift register more or less tries to correlate what is read in the > >> present cycle with the previous ones. > > >> Is it correct to say that, in this case, "it doesn't matter"? > > >> Now, completely agreeing with your observation, I am still puzzled by > >> the fact that the even the RTL simulation (which I assume does not tak= e > >> any delays into account) is not working properly. If you have a look a= t > >> the simulation results, this is absolutely not a shift register! > > >> It seems that Altera's synthesis tool infers something quite > >> different... but why?? > > >> Pere > > > Your design is synchronous, but you have more than one clock, so you > > need to be sure of the timing of signals that cross the clock > > domains. =A0For example, the signals sr_clear, sr_burst_ena and > > dec_shift_ena seem to be used in both the clk and the s_sample clock > > domains without being synchonized. =A0I guess that might be ok if you > > can make sure the delays in the s_sample clock don't result in one of > > these signals changing on the edge of either clock. > > > If the simulation is not what you want, then there is likely something > > wrong with the code. =A0But remember that while the simulation does not > > account for logic delays, there are delta delays that mean signals > > clocked by clk will have already changed by the time the remaining > > code sees the change in s_sample. > > > Rick > > Hi, Rick > > the signals you are mentioning are being updated in the same > process(clk) that creates s_sample. They are only read in the > process(s_sample) as shown. However, there are no timing issues with > this showing up in the post-route simulation (in hindsight, perhaps I > was too lucky with this). > > Otoh, the main point is that one simulation does what I want (and > corresponds with the intended behaviour: the GHDL result) but the other > one does not! GHDL simulates the semantics of VHDL, and Simulink > simulates what Quartus' synthesis has inferred -which does not seem to > be the same! > > Pere > > Pere I don't know why you are expecting to see your problems or solutions in any simulation. A post route simulation uses typical timings and can't be expected to be 100% realistic, even a chip can't be expected to be the same as another chip. That is why they use synchronous concepts, meet the cycle timing and all other timing issues are handled by the chip qualification and the design tools. If the signal is generated in the clk domain and s_sample is generated in the clk domain, you can't predict which delay will be longer and you have a race condition between all the signals and the s_sample clock. One thing that would help is to generate the signals on one edge of clk and generate s_sample on the other edge of clk. Then you know the timing on a course level and can constrain the timing of paths from the clk to the s_sample clock domain... or just use an enable instead of generating a new clock. If you don't believe the timing is a problem, draw a timing diagram showing *all* delays. You will see the routing delay of s_sample can be giving you trouble. RickArticle: 154021
On Jul 12, 10:42=A0am, o pere o <m...@somewhere.net> wrote: > On 07/12/2012 02:55 PM, glen herrmannsfeldt wrote: > > > > o pere o<m...@somewhere.net> =A0wrote: > > > (snip, I wrote) > >>> You don't show where dec_shift_ena comes from. > > >> Sorry for the omission! > > >> dec_shift_ena is generated as follows. > >> First, I have a counter the is reset periodically: > > >> clock_counter: process(clk) --counter counting over the symbol length > >> =A0 =A0begin > >> =A0 =A0 =A0if rising_edge(clk) then > >> =A0 =A0 =A0 =A0 if tc_symbol =3D '1' then > >> =A0 =A0 =A0 =A0 =A0 =A0clk_count<=3D 0; > >> =A0 =A0 =A0 =A0 else > >> =A0 =A0 =A0 =A0 =A0 =A0clk_count<=3D clk_count + 1; > >> =A0 =A0 =A0 =A0 end if; > >> =A0 =A0 =A0end if; > >> =A0 =A0end process clock_counter; > >> =A0 =A0tc_symbol<=3D '1' when clk_count=3Dc_ticks_per_symbol-1 else '0= '; > > >> =A0From this counter, I also generate some time markers, such as > > >> =A0 =A0dec_shift_ena_pre<=3D '1' when (clk_count>=3D ...) and (...) > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else '0'; > > >> which are resynchronized in > > > I read verilog much better, but this sounds suspicious. > > Why does it need resynchronizing? > > Being a combinational assignment, it is subject to glitches. The > instants where they happen seemed to upset the post-route simulation, > with complaints of hold time to short (iirc). BTW, the timing analyser > did not complain at all. Making them a registered signal (and > pre-compensating the one-cycle delay) cleared glitches and moved the > transitions so that simulation goes ok. > > Pere > > > >> =A0 process(clk) > >> =A0 =A0begin > >> =A0 =A0 =A0 if rising_edge(clk) then > >> =A0 =A0 =A0 =A0 =A0... > >> =A0 =A0 =A0 =A0 =A0dec_shift_ena<=3D dec_shift_ena_pre; > >> =A0 =A0 =A0 end if; > >> =A0 =A0end process; > > > -- glen There is a problem. dec_shift_ena was transitioning in the setup/hold time window of s_sample because the logic/routing delays of the two paths were too close to equal. The signal needs to be synced, but not to the clk domain, to the s_sample domain! Better to change the timing altogether by generating s_sample on the opposite edge of clk... or like I said above, use an enable rather than a new clock. RickArticle: 154022
On Thursday, July 12, 2012 12:51:18 PM UTC-4, rickman wrote: > > There is a problem. dec_shift_ena was transitioning in the setup/hold > time window of s_sample because the logic/routing delays of the two > paths were too close to equal. The signal needs to be synced, but not > to the clk domain, to the s_sample domain! Better to change the > timing altogether by generating s_sample on the opposite edge of > clk... or like I said above, use an enable rather than a new clock. > > Rick I pointed out exactly these points (use a clock enable and that he was using two signals in two different clock domains) in the very first reply to his post...maybe it will click this time. KJArticle: 154023
On 07/11/2012 01:23 PM, o pere o wrote: > Hi, > > I am not an FPGA expert although this is not my first design. The > problem that I am having for two days now, is that I am observing > different results when simulating a design in GHDL and in Modelsim > ALTERA starter edition. > > The design includes a shift register. The significant code is: > > read_sro : process(s_sample) > begin > if rising_edge(s_sample) then > if ... --irrelevant here > end if; > if ... > end if; > if sr_burst_ena = '1' then --First phase: store data in shift_reg > new_data <= sr_sro_wave & new_data(c_burst_no-1 downto 1); > elsif dec_shift_ena = '1' then --Second phase: rotate data > > new_data <= new_data(0) & new_data(c_burst_no-1 downto 1); > > --irrelevant, but included for completeness > max_cnt <= max_cnt + 1; > if usum > max then > max <= usum; > max_pos <= max_cnt; > end if; > end if; > end if; > end process read_sro; > > the clock signal s_sample is obtained from the main 50 MHz clock with > the following process: > > sr_signals : process(clk) > begin > if rising_edge(clk) then > if sr_clear = '1' or sr_burst_ena = '1' or dec_shift_ena ='1' then > s_sample <= not s_sample; > end if; > ... > end if; > end process sr_signals; > > I have uploaded some screenshots here: > > 1- ghdl+gtkwave result http://tinypic.com/r/wklimq/6 > 2- simulink http://tinypic.com/r/2le743t/6 > > It may be seen that the input signal (top signal in the GHDL result and > third from the top in SIMULINK) is zero during the first 5 s_sample > clocks, then is at one during 10 clocks and zero again for the rest of > the (up to 20) clocks. > > The GHDL simulation shows up ok, with the register correctly loaded with > 0000011111111110000 after the 20 clocks, however Altera's quartus gives > 00000111110000011111. > > Exactly the same file is being fed to to Quartus II for synthesis!! But > Alteras RTL (and gate level) simulations do not behave as intended. > > Is there something with the coding style than can make Quartus infer an > absolutely different behaviour? Any help is very much appreciated!! > > Pere > Thanks to everybody for your inputs. Making the whole design work on only one clock (with suitable enables) solves the issue. This is really not a surprise. However, I still have some questions on this. If I built my design from, lets say, discrete components, I might have problems with setup and hold times at the shift register (SR) input, but I would NEVER EVER get the results that showed up in the simulation: The SR was initially cleared. The serial input to the SR is zero at the first clock but, surprisingly, a one appears at the 9th (!!) SR output after the first edge of the clock. Can anybody find a plausible explanation for this? The second question is, is there a way to tell Quartus that it should synthesize something that resembles the physical circuit? I did tell Quartus that s_sample was a clock (and told the frequency), however this was obviously not sufficient. Any thoughts? PereArticle: 154024
On Jul 13, 11:20=A0am, o pere o <m...@somewhere.net> wrote: > On 07/11/2012 01:23 PM, o pere o wrote: > > > > > > > > > > > Hi, > > > I am not an FPGA expert although this is not my first design. The > > problem that I am having for two days now, is that I am observing > > different results when simulating a design in GHDL and in Modelsim > > ALTERA starter edition. > > > The design includes a shift register. The significant code is: > > > read_sro : process(s_sample) > > begin > > if rising_edge(s_sample) then > > if ... --irrelevant here > > end if; > > if ... > > end if; > > if sr_burst_ena =3D '1' then --First phase: store data in shift_reg > > new_data <=3D sr_sro_wave & new_data(c_burst_no-1 downto 1); > > elsif dec_shift_ena =3D '1' then --Second phase: rotate data > > > new_data <=3D new_data(0) & new_data(c_burst_no-1 downto 1); > > > --irrelevant, but included for completeness > > max_cnt <=3D max_cnt + 1; > > if usum > max then > > max <=3D usum; > > max_pos <=3D max_cnt; > > end if; > > end if; > > end if; > > end process read_sro; > > > the clock signal s_sample is obtained from the main 50 MHz clock with > > the following process: > > > sr_signals : process(clk) > > begin > > if rising_edge(clk) then > > if sr_clear =3D '1' or sr_burst_ena =3D '1' or dec_shift_ena =3D'1' the= n > > s_sample <=3D not s_sample; > > end if; > > ... > > end if; > > end process sr_signals; > > > I have uploaded some screenshots here: > > > 1- ghdl+gtkwave resulthttp://tinypic.com/r/wklimq/6 > > 2- simulinkhttp://tinypic.com/r/2le743t/6 > > > It may be seen that the input signal (top signal in the GHDL result and > > third from the top in SIMULINK) is zero during the first 5 s_sample > > clocks, then is at one during 10 clocks and zero again for the rest of > > the (up to 20) clocks. > > > The GHDL simulation shows up ok, with the register correctly loaded wit= h > > 0000011111111110000 after the 20 clocks, however Altera's quartus gives > > 00000111110000011111. > > > Exactly the same file is being fed to to Quartus II for synthesis!! But > > Alteras RTL (and gate level) simulations do not behave as intended. > > > Is there something with the coding style than can make Quartus infer an > > absolutely different behaviour? Any help is very much appreciated!! > > > Pere > > Thanks to everybody for your inputs. Making the whole design work on > only one clock (with suitable enables) solves the issue. This is really > not a surprise. > > However, I still have some questions on this. If I built my design from, > lets say, discrete components, I might have problems with setup and hold > times at the shift register (SR) input, but I would NEVER EVER get the > results that showed up in the simulation: > > The SR was initially cleared. The serial input to the SR is zero at the > first clock but, surprisingly, a one appears at the 9th (!!) SR output > after the first edge of the clock. Can anybody find a plausible > explanation for this? > > The second question is, is there a way to tell Quartus that it should > synthesize something that resembles the physical circuit? I did tell > Quartus that s_sample was a clock (and told the frequency), however this > was obviously not sufficient. Any thoughts? > > Pere I can't answer question one, but the answer is in the code and the simulation. If necessary you will need to step through the code that assigns a value to the SR, but the answer will be there. The real point is that it doesn't matter really. The simulation told you something was wrong and you found the problem. Is it important to understand how the error was generated? The second question is easy. You don't tell the tool what the "physical circuit" is really. The tool tells you! Telling Quartus that your clock is a clock shouldn't be needed as it can figure that out because the signal is clocking FFs. There was no problem with the tool. The problem was exactly as KJ described in his first post, once you create a clock from logic, you can't control the skew between the two clocks and so lose control over setup and hold times. The tool also looses control over this as it depends on things the tool can't control or even know about, the exact detailed timing of the chip. In summary, generating clocks is bad ju-ju. Don't cross the beams. Rick
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