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
In article <jpk3g1$pmp$1@speranza.aioe.org>, glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: >It seems to me that a tree of glitch-free LUTs is glitch-free, >but see what others say. I don't think so. Consider this example: LUT1 is OR(LUT2, LUT3) LUT2 is XOR(A, 0) LUT3 is XOR(A, 1) In the static case, it doesn't matter what A is. Now switch A. With appropraite routing delays you can make a glitch. -- These are my opinions. I hate spam.Article: 153801
On Thursday, May 24, 2012 11:34:26 AM UTC+12, Rob Gaddi wrote: > I've got a 24-input AND gate that I'd like to avoid having add another > register delay to before I toss it across a clock boundary. A 24 wide and, is an unusual Clock Mux, and Glitches usually only bother a design if they are on a clock tree. Is this clocking something ? So long as the wide-AND output meets your clock domain Tsu.Th, why are you worried about glitches ?Article: 153802
"Rob Gaddi" <rgaddi@technologyhighland.invalid> wrote in message news:20120523163426.7e77de05@rg.highlandtechnology.com... > seems like neither structure should glitch. "Try it and see" doesn't > work; testing all 2^24 combinations and trying to determine whether I > get a glitch would be a beast of an effort. Doesn't seem it should be that difficult. 2^24 is only 16 million, not all that large compared with the 100's of MHz clocks.Article: 153803
>"Rob Gaddi" <rgaddi@technologyhighland.invalid> wrote in message >news:20120523163426.7e77de05@rg.highlandtechnology.com... >> seems like neither structure should glitch. "Try it and see" doesn't >> work; testing all 2^24 combinations and trying to determine whether I >> get a glitch would be a beast of an effort. > >Doesn't seem it should be that difficult. 2^24 is only 16 million, not all >that large compared with the 100's of MHz clocks. > > And the most important part of that can be done by a walking-zero test: Start with all zero. Then all one. 24-stage walking-zero. All one. All zero. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153804
Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote: > In article <jpk3g1$pmp$1@speranza.aioe.org>, (snip, I wrote) >>It seems to me that a tree of glitch-free LUTs is glitch-free, >>but see what others say. > I don't think so. > Consider this example: > LUT1 is OR(LUT2, LUT3) > LUT2 is XOR(A, 0) > LUT3 is XOR(A, 1) > In the static case, it doesn't matter what A is. > Now switch A. With appropraite routing delays you can make > a glitch. But note that I specifically excluded ones that depend on timing delays, but you snipped out that part. Note that non-LUT logic can glitch with timing delays, so that is nothing new. Depending on design, LUT logic can glitch even in cases where gates wouldn't, which is why FPGAs use glitch-free LUTs. -- glenArticle: 153805
j.m.granville@gmail.com wrote: > On Thursday, May 24, 2012 11:34:26 AM UTC+12, Rob Gaddi wrote: >> I've got a 24-input AND gate that I'd like to avoid having add another >> register delay to before I toss it across a clock boundary. > > A 24 wide and, is an unusual Clock Mux, and Glitches usually only bother a design if they are on a clock tree. Is this clocking something ? > > So long as the wide-AND output meets your clock domain Tsu.Th, why are you worried about glitches ? Maybe you missed the fact that he's crossing clock domains, so there's no way to ensure setup and hold time. The walking 0's case is really the worst case for an AND gate. It guarantees glitches if your inputs aren't set up to "break before make". i.e. if you go from 1110111 to 1101111 without going to 1100111 in between, you'll get a glitch if there are enough routing delay differences to pass through the LUT. You'll need to walk the zeroes in all directions to ensure complete timing test coverage. This means 276 transitions for the 24-bit case (combination of 24 taken 2 at a time). If your input logic can guarantee that you'll never make this sort of state transition, then you won't get glitches. I think it would be easier to add another register after the AND gate and then you just need to meet Tsu and Th. - GaborArticle: 153806
> > Convert this to JPEG > > over Ethernet with a FpGa as implemented by the SoC Milkymist > > project. > > > > Ques: Where would one option an IP for this? > > So You need to convert video frames to JPEG or to MPEG4? MPEG4 would be huge > and cost a lot... Afaik JointWave could offer something for You. If you require JPEG, we can offer a small, high-performance and reasonable priced encoder (and also decoder): http://www.entner-electronics.com/tl/index.php/jpeg-codec.html Thomas www.entner-electronics.com Also check out our EEBlaster: http://www.entner-electronics.com/tl/index.php/eeblaster.htmlArticle: 153807
Gabor <gabor@szakacs.invalid> wrote: > j.m.granville@gmail.com wrote: >> On Thursday, May 24, 2012 11:34:26 AM UTC+12, Rob Gaddi wrote: >>> I've got a 24-input AND gate that I'd like to avoid having add another >>> register delay to before I toss it across a clock boundary. >> A 24 wide and, is an unusual Clock Mux, and Glitches usually >> only bother a design if they are on a clock tree. Is this >> clocking something ? > Maybe you missed the fact that he's crossing clock domains, > so there's no way to ensure setup and hold time. That is true, but if there aren't any glitches it will go 1 either one cycle or the next. > The walking 0's case is really the worst case for an AND gate. > It guarantees glitches if your inputs aren't set up to "break > before make". i.e. if you go from 1110111 to 1101111 without > going to 1100111 in between, you'll get a glitch if there > are enough routing delay differences to pass through the LUT. Given that it is an AND of done bits, in the usual case each one transitions from 0 to 1 until all are 1. If you use a traditional SRAM, with row select logic, the bits of each row coming out, and then a MUX to select one of the rows, even if the inputs change between states that don't even come close to a cell of a different value, the output can still glitch. The delays through different parts of the DEMUX row select, or the MUX column select can be different. Fill up a SRAM such that only one cell is 1, hold one input at 0, and go through all combinations of the other inputs. For that matter, fill the array with all 0, and go through all combinations of inputs. An SRAM can still glitch to 1. The glitchless LUTs used in FPGAs are designed not to do that. If you hold one input a 0, for all combinations of other inputs, even with timing differences, the output should stay zero. > You'll need to walk the zeroes in all directions to ensure > complete timing test coverage. This means 276 transitions > for the 24-bit case (combination of 24 taken 2 at a time). > If your input logic can guarantee that you'll never make this > sort of state transition, then you won't get glitches. I > think it would be easier to add another register after the > AND gate and then you just need to meet Tsu and Th. Since the 24 bit AND will be generated as some number of LUTs feeding either another LUT or carry chain AND logic, another possibility is to put a register between the two levels of AND. It seems to me that isn't necessary, but could be done. -- glenArticle: 153808
On May 23, 6:34=A0pm, Rob Gaddi <rga...@technologyhighland.invalid> wrote: > I've got a 24-input AND gate that I'd like to avoid having add another > register delay to before I toss it across a clock boundary. > > =A0 =A0 =A0 =A0 all_done <=3D and_reduce(done); > > If I just do it, AND it all together without a flop on the output, does > anyone know whether I'll get transition glitches (an output of 1 when > not all inputs are 1)? > > I seem to remember something about individual LUTs being glitch-free, > and the synthesizer has to compose my giant AND out of either a LUT > tree or a mess o' LUTs "wire-and" driving a carry chain, =A0Offhand, it > seems like neither structure should glitch. =A0"Try it and see" doesn't > work; testing all 2^24 combinations and trying to determine whether I > get a glitch would be a beast of an effort. > > Anyone know offhand? > > -- > Rob Gaddi, Highland Technology --www.highlandtechnology.com > Email address domain is currently out of order. =A0See above to fix. Unless you can guarantee that no more than one of the done bits changes at any one time, you WILL get glitches sooner or later, and sooner or later they will line up with the (async) receiveing clock, and you will have bad data transferred, if you simply leave it up to the synthesis tool to implement the LUT/Carry structure. If you force the synthesis tool to implement a specific AND structure, you may be able to avoid glitches based on how the done bits collectively behave. For example, if you are only concerned with the leading edge of all_done, and the done bits monotonically transition from 0 to 1 (never go back to zero until you don't care), you can probably get some structure to work reliably. If you don't have time for an additional clock cycle in the source domain, do you have time for a half-cycle (register all_done on the opposite edge of the source clock)? Depending on the relative clock frequencies and your latency requirements, you may have time to "filter" the all_done signal in the destination clock domain, and thus reject glitches. There are probably many ways to do this, but the conventional approach of registering all_done in the source domain prior to sampling in the destination domain is the easiest by far to verify. AndyArticle: 153809
glen herrmannsfeldt wrote: > > It seems to me that a tree of glitch-free LUTs is glitch-free, > but see what others say. It seems to me that routing delays will make this not work. Yes, for exactly one input changing state at a time, your statement MIGHT still be true, but for multiple inputs changing state at the same time, such as one input going high while one other goes low, the propagation of these signals through the routing will certainly cause glitches. Now, maybe there is some simplification possible depending on how this is used. If the normal state is all inputs false, and occasionally a few inputs are true, then this might never glitch. If the normal state is 23 inputs true, and the pattern of which ones are true changes, then I would expect glitches are possible. JonArticle: 153810
On Thu, 24 May 2012 14:24:53 +0000 (UTC) glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > > Given that it is an AND of done bits, in the usual case each > one transitions from 0 to 1 until all are 1. > That's exactly right, and I feel silly for not having mentioned it out front. The assertion of all_done, shifted onto a different clock domain, is what goes back around and asynchronously clears all of the individual done flags. All of you stop wincing; I know exactly how bad that sounds and I swear to god there are reasons it had to be this way. So the only possible modes of operation are: all_done is low, and all I want is for it to never erroneously transition high until all 24 done flags come up. Once it's up it stays up. all_done has been high, causing a 20 ns asynchronous clear pulse to hit all the done flags, dropping them all. In this case, all_done should drop once and only once as the various path skews from the pulse to the clear to the AND gate structure all work themselves out. The reason I'm concerned about glitches is, because all_done is sampled asynchronously to it's originating clock, a glitch could happen to get captured, with some unknown but small probability. The reason I can't just test it out is the same: given that if a glitch exists there's only a small probability of capturing it, I might test a given sequence 10,000 times without catching a glitch that I would have seen on the 10,001st. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 153811
Rob Gaddi <rgaddi@technologyhighland.invalid> wrote: > On Thu, 24 May 2012 14:24:53 +0000 (UTC) (snip, I wrote) >> Given that it is an AND of done bits, in the usual case each >> one transitions from 0 to 1 until all are 1. > That's exactly right, and I feel silly for not having mentioned > it out front. The assertion of all_done, shifted onto a different > clock domain, is what goes back around and asynchronously > clears all of the individual done flags. You mean a register between all_done and when it goes back around? I would call it asynchronous if there wasn't a register there. > All of you stop wincing; I know exactly how bad that sounds and I > swear to god there are reasons it had to be this way. If there is a zero hold time register (And even if not, the 0 signal won't make it back fast enough to cause problems.) then that is fine. If there is no register around the loop, then it takes somewhat more analysis. > So the only possible modes of operation are: > all_done is low, and all I want is for it to never erroneously > transition high until all 24 done flags come up. Once it's up it > stays up. You don't say about any possibly glitches on inputs to the AND. > all_done has been high, causing a 20 ns asynchronous clear pulse to > hit all the done flags, dropping them all. In this case, all_done > should drop once and only once as the various path skews from the > pulse to the clear to the AND gate structure all work themselves out. The only way you could know the pulse was 20ns is coming from a FF clocked at 50MHz, so I will assume that. In that case, you only have to worry about glitches that last longer than 20ns. That is, after all_done has been latched, could it glitch low 20ns later. The AND gate shouldn't do that itself, but if its inputs can, that could still be a problem. But 20ns is pretty long, so you should be able to prove that can't happen. > The reason I'm concerned about glitches is, because all_done is sampled > asynchronously to it's originating clock, a glitch could happen to get > captured, with some unknown but small probability. The reason I can't > just test it out is the same: given that if a glitch exists there's > only a small probability of capturing it, I might test a given > sequence 10,000 times without catching a glitch that I would have seen > on the 10,001st. There is another problem not discussed yet: metastability. Metastability is completely separate from race conditions, but people sometimes get the two confused. You need to separately show that metatability isn't a problem. I am still not sure where the registers are, so I won't try to say more about metastability. Also, if there is no register around the loop (which seems unlikely mentioning clock domains) then it takes different treatment. -- glenArticle: 153812
Rob Gaddi <rgaddi@technologyhighland.invalid> wrote: >I've got a 24-input AND gate that I'd like to avoid having add another >register delay to before I toss it across a clock boundary. > > all_done <= and_reduce(done); > >If I just do it, AND it all together without a flop on the output, does >anyone know whether I'll get transition glitches (an output of 1 when >not all inputs are 1)? > >I seem to remember something about individual LUTs being glitch-free, >and the synthesizer has to compose my giant AND out of either a LUT >tree or a mess o' LUTs "wire-and" driving a carry chain, Offhand, it >seems like neither structure should glitch. "Try it and see" doesn't >work; testing all 2^24 combinations and trying to determine whether I >get a glitch would be a beast of an effort. > >Anyone know offhand? You'll get glitches for sure due to different routing delays between the LUTs themselves and the input signals. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 153813
On Friday, May 25, 2012 7:13:51 AM UTC+12, Rob Gaddi wrote: > The reason I'm concerned about glitches is, because all_done is sampled > asynchronously to it's originating clock, a glitch could happen to get > captured, with some unknown but small probability. The reason I can't > just test it out is the same: given that if a glitch exists there's > only a small probability of capturing it, I might test a given > sequence 10,000 times without catching a glitch that I would have seen > on the 10,001st. Since this seems to be a slow handshake, and you do not expect it to spin at 50MHz, but you do want to avoid another register in the 'go' pathway, why not design your state handshake, so single-pulse glitches are tolerated/ignored ?Article: 153814
>On Thu, 24 May 2012 14:24:53 +0000 (UTC) >glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > >> >> Given that it is an AND of done bits, in the usual case each >> one transitions from 0 to 1 until all are 1. >> > >That's exactly right, and I feel silly for not having mentioned it out >front. The assertion of all_done, shifted onto a different clock >domain, is what goes back around and asynchronously >clears all of the individual done flags. > >All of you stop wincing; I know exactly how bad that sounds and I >swear to god there are reasons it had to be this way. > >So the only possible modes of operation are: > all_done is low, and all I want is for it to never erroneously > transition high until all 24 done flags come up. Once it's up it > stays up. > > all_done has been high, causing a 20 ns asynchronous clear pulse to > hit all the done flags, dropping them all. In this case, all_done > should drop once and only once as the various path skews from the > pulse to the clear to the AND gate structure all work themselves out. > >The reason I'm concerned about glitches is, because all_done is sampled >asynchronously to it's originating clock, a glitch could happen to get >captured, with some unknown but small probability. The reason I can't >just test it out is the same: given that if a glitch exists there's >only a small probability of capturing it, I might test a given >sequence 10,000 times without catching a glitch that I would have seen >on the 10,001st. > >-- >Rob Gaddi, Highland Technology -- www.highlandtechnology.com >Email address domain is currently out of order. See above to fix. > Perhaps a silly question, but why can you not register 'all_done'? For extra safety, don't assert 'clear_dones' until 2 or 3 successive highs. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153815
Hi all I got stuck with my design. I'm planning to use microblaze in ML505 board to read my full custom chip output and display to hyperterminal. I've found one tutorial about read DIP switch using microblaze, but here I want the output of my external chip to be read by microblaze. I'm confused of the device_ID that I should use in my programming so that the microbalze can read the signal. FYI, I want to test my chip by driven the input signal using test vector that I've designed using VHDL in Virtex-5(ML505)and the test vector output will be the input of my chip. Then my chip will produce the output and display at hyperterminal using microblaze. Hope somebody can help me with this. Thanks --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153816
"nana_7488" <nana_7488@n_o_s_p_a_m.yahoo.com> wrote in message news:SNWdnf0AHOmu_SLSnZ2dnUVZ_gydnZ2d@giganews.com... > Hi all > I got stuck with my design. I'm planning to use microblaze in ML505 board > to read my full custom chip output and display to hyperterminal. > I've found one tutorial about read DIP switch using microblaze, but here I > want the output of my external chip to be read by microblaze. > I'm confused of the device_ID that I should use in my programming so that > the microbalze can read the signal. > > FYI, I want to test my chip by driven the input signal using test vector > that I've designed using VHDL in Virtex-5(ML505)and the test vector output > will be the input of my chip. Then my chip will produce the output and > display at hyperterminal using microblaze. ChipscopePro does that, I think. I mean, I know what chipscope does; just not sure if you meant what I thought you were trying to say. There's a 30 day free eval license. The microblaze needs the embedded tools edition. That's dandy if you have it already. (In which case, you already have ChipscopePro.) Eval license for that is also available. I wouldn't take the microblaze approach, to solve apparently a small problem with a much larger project. I'm assuming here that if the data rate is slow enough to make a serial terminal feasible, it's a tiny tiny problem. Gpio interface is the answer to your dipswitch question. Anything much more complex really would be better on chipscope.Article: 153817
On Wed, 23 May 2012 10:19:05 -0700 (PDT) Ed McGettigan <ed.mcgettigan@xilinx.com> wrote: > Yes, this is why I asked (although it was in the original post). I > have confirmed that the problem only happens with the new parser > (Spartan-6, Virtex-6, 7 Series) and is not present in the original > parser. This is still true for the ISE 14.1 release. > > I filed an intenal change request/bug report on the issue to get it > fixed. > > Note: I need to stop using Google groups because they continue to drop > my posts (2nd try) unless I logout and then back in again. > > Ed McGettigan > -- > Xilinx Inc. Thanks for the attention! Since Xilinx doesn't want bug reports from university students, I figured this group was an easy way to get some more eyes on the issue and hopefully get it fixed at some point. ChrisArticle: 153818
[This followup was posted to comp.arch.fpga and a copy was sent to the cited author.] In article <20120518175419.3278d371@kruskal.chead>, chead@is.invalid says... > I think this may have hit the nail on the head. > > Chris Sounds like it is hitting Chris on the head too. :-) -- Michael Karas Carousel Design Solutions http://www.carousel-design.comArticle: 153819
>Hi all >I got stuck with my design. I'm planning to use microblaze in ML505 board >to read my full custom chip output and display to hyperterminal. >I've found one tutorial about read DIP switch using microblaze, but here I >want the output of my external chip to be read by microblaze. >I'm confused of the device_ID that I should use in my programming so that >the microbalze can read the signal. > >FYI, I want to test my chip by driven the input signal using test vector >that I've designed using VHDL in Virtex-5(ML505)and the test vector output >will be the input of my chip. Then my chip will produce the output and >display at hyperterminal using microblaze. > >Hope somebody can help me with this. >Thanks What is the interface of the "full custon chip" that you want to read? Or is it just a bunch of signals? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153820
Does anyone have experience of using the Altera and Xilinx embedded software? I have been using EDK but I am getting very frustrated with it. It seems that every new release includes a generous helping of bugs. I seem to find myself wasting hours just trying to get a design to be implemented. For example the 14.1 release now seems to have some problems with the interrupt controller, yet it was ok in the previous release. Does the Altera software have as many bugs? TIA Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153821
On Monday, 18 October 2010 17:04:55 UTC+5:30, neosis wrote: > Hi all, I'm using ISE 12.3 to implement a design. > I generate a verilog netlist which contains cells of the simprim library. > I used this command line to do that : > netgen -w -ecn conformal -ne -mhf clockbuf > I obtained 2 verilog files : glbl.v & clockbuf_ecn.v > > Then I take this netlist and do some changes on it ( split it in parts for > example ). But if I start a new project whith the new files, ise can't find > simprims library. > > I tried also to start another new project with these 2 files( with > nochanges), and I included all verilog files of used cells from the simprim > library. and here is what I obtain : > > ERROR:HDLCompilers:244 - > "../../work/xilinx/opt1/ISE_DS/ISE/verilog/src/simprims/X_OBUF.v" line 36 > Name 'glbl.GTS' could not be resolved > ERROR:HDLCompilers:185 - > "../../work/xilinx/opt1/ISE_DS/ISE/verilog/src/simprims/X_OBUF.v" line 36 > Illegal right hand side of continuous assign > ERROR:HDLCompilers:244 - > "../../work/xilinx/opt1/ISE_DS/ISE/verilog/src/simprims/X_FF.v" line 42 > Name 'glbl.GSR' could not be resolved > ERROR:HDLCompilers:185 - > "../../work/xilinx/opt1/ISE_DS/ISE/verilog/src/simprims/X_FF.v" line 42 > Illegal right hand side of continuous assign > ERROR:HDLCompilers:244 - > "../../work/xilinx/opt1/ISE_DS/ISE/verilog/src/simprims/X_BUFGMUX.v" line > 46 Name 'glbl.GSR' could not be resolved > ERROR:HDLCompilers:185 - > "../../work/xilinx/opt1/ISE_DS/ISE/verilog/src/simprims/X_BUFGMUX.v" line > 46 Illegal right hand side of continuous assign > > Can anyone explain me what to do? > thx for your help. > > > > --------------------------------------- > Posted through http://www.FPGARelated.com I am facing the same problem. Did you figure out how to resolve this problem?Article: 153822
maxascent wrote: > Does anyone have experience of using the Altera and Xilinx embedded > software? I have been using EDK but I am getting very frustrated with it. > It seems that every new release includes a generous helping of bugs. I > seem to find myself wasting hours just trying to get a design to be > implemented. For example the 14.1 release now seems to have some problems > with the interrupt controller, yet it was ok in the previous release. Does > the Altera software have as many bugs? I am not using the very latest Xilinx chip products, so I don't have to use their very latest software. I am using 10.1, as it supports the relatively modern parts I use as well as some of the older parts that are still used in some of our more mature designs. Sometimes funny things happen and I think it is using old versions of the vhdl files, but exiting the Ise environment and starting it up again seems to clear it up. Otherwise, I have had no significant problems with Ise 10.1 JonArticle: 153823
Hi all, I have a Spartan-6 LX45 board with a whole bunch of lvds going in and out at a rate of 780mbps. After running out of pins I was forced to put two lvds receiving pairs into a different bank from the rest of the bus. To make matters worse this bank has an active MCB. All of the tx/rx lvds is synchronous with a clock I have inside the fpga so both transmit and receive are handled through the BUFPLL method suggested in XAPP1064. Receive channels are using the differential phase detector mode of IDELAY2 and ISERDES2. The bank with the MCB presents a unique challenge because the MCB makes use of both BUFPLL resources available along that edge of the device. On the bright side I am able to run the memory interface at the same 780mbps potentially allowing me to use the same BUFPLL technique used on other edges of the device. The problem is that the MCB requires the BUFPLL to be run with DIVIDE=2 essentially causing the fabric side of the ISERDES2 to run at 390mhz! In the XAPP1064 source code I found the following note relating to the instantiation of ISERDES2: DATA_WIDTH => 6, -- SERDES word width. This should match the setting is BUFPLL I wonder what exactly "should" means. Say that I have BUFPLL with divide=2 and ISERDES with width=6. What is really going to happen? Looking at figure 3-1 on page 80 of UG381. It looks to me as though it would work fine. A bitslip machine would be able to line of which of the 3 strobes was actually the correct one.Article: 153824
I'm learning the diff between variables and signals,
and I've found this site:
http://esd.cs.ucr.edu/labs/tutorial/sig_var.vhd
with a corresponding picture here:
http://esd.cs.ucr.edu/labs/tutorial/sig_var.jpg
I've changed the source file to this
library ieee;
use ieee.std_logic_1164.all;
entity sig_var is port (
d1, d2, d3 : in std_logic;
res1, res2, res3 : out std_logic);
end sig_var;
architecture behv of sig_var is
signal sig_s1: std_logic;
signal sig_s2: std_logic;
begin
proc1: process(d1,d2,d3)
variable var_s1: std_logic;
begin
var_s1 := d1 and d2;
res1 <= var_s1 xor d3;
end process;
proc2: process (d1,d2,d3)
begin
sig_s1 <= d1 and d2;
res2 <= sig_s1 xor d3;
end process;
sig_s2 <= d1 and d2;
res3 <= sig_s2 xor d3;
end behv;
and this are the simulation results:
http://img521.imageshack.us/img521/346/simulations.gif
As you can see, behavioral and post-route don't match.
Is there something wrong with the VHD source,
or I just don't get the idea behind behavioral simulation?
Post route works as I have expected.
(I've started this thread as a variable/signal issue,
but it turned into behavioral/post-route simulation.)
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