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 wrote: > <snip> > An analogy is a pencil balanced on its rounded eraser end (I used to say > a perfectly sharp point, but some started to argue about how sharp it > could be before quantum mechanics kicked in... jeeeez!). They may have been more relevant ( to the point :) than they realised.. > Like a switching FF, it will take some time to go to a stable state. But it > can be just close enough to the perfect balance point that it might take > a while to move off center. The closer to the balance point, the longer > it can take, so there is no maximum metastable time. I'm not sure this assertion can apply forever. See Peter A's notes on metastable times, that reflected to very narrow time windows, and working that to a Wave-transit time, you get less than the order of a gate-length. Given this extremely short physical equivalence, it opens the idea of a triple register, using traces as delay lines, and then taking a vote of the outputs on the basis that all 3 cannot have the same metastable lifetimes. I did ask if anyone knew how many electrons were 'active' in this time window, but it must start to get quantized by electron charge at some point. > I have tried to analyze the behaviour of such an analogy in the presence > of noise, but I don't have the tools to do it rigorously. It may well > be possible to shorten the metastable time with noise, but I really > can't prove it one way or the other. Thermal noise maybe, it's hard to see how electrical noise will help, due to the very narrow effective windows. -jgArticle: 49651
>I have tried to analyze the behaviour of such an analogy in the presence >of noise, but I don't have the tools to do it rigorously. It may well >be possible to shorten the metastable time with noise, but I really >can't prove it one way or the other. Somebody mentioned noise recently, but I'll repeat. It doesn't work. It kicks the system toward the stable point just as often as it helps you by kicking the system in the right direction. When metastability was first becoming known to the design world, there was a flurry of "fixes" proposed. All are bogus, bordering on snakeoil. The classic is a few gates to detect the metastable state and reset the FF. That's a recipe for runt pulses which puts you right back where you started. Basically, you have to believe in metastability. Once you do that, then you can stop paying attention to noise and kludges. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 49652
> Given this extremely short physical equivalence, it opens the idea of >a triple register, using traces as delay lines, and then taking a vote >of the outputs on the basis that all 3 cannot have the same metastable >lifetimes. That sounds like one of the kludges I was talking about. What do you do if one path says 0, the other says 1, and the third goes metastable? You can't "fix" metastability. Get suspicious when somebody tries, or appears to be trying. It means they don't understand it. As Peter often says, you can make things good enough, especially with modern silicon. But the basic mechanism is still exponential decay. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 49653
Bob Perlman <bobsrefusebin@hotmail.com> wrote in message news:<q80ituogem7vbhnoard9tm0bdlalsa84ev@4ax.com>... > On 18 Nov 2002 06:43:15 -0800, already5chosen@yahoo.com (Michael S) > wrote: > > >I never studied the theory of metastable flip-flops. But intuitively I > >see metastable state as a very small local minimum on the energy > >curve. At the higher temperature the thermal noise can be strong > >enough to rescue the flip-flop out of this state to the stable one. > >It's all my speculations, may be, I erroneously apply the lows of > >microworld lows to the macroworld phenomenon ? > > Back when the phenomenon of metastability was first observed and > discussed, some people suggested that metastable behavior could be > circumvented, or at least improved, by injecting noise that would move > the offending device away from its metastable point. But others > pointed out that while noise might move a node out of metastability, > it was equally likely that noise would move an almost-metastable node > into metastability. > > Bob Perlman > Cambrian Design Works I feel those "others" were wrong. There is relatively short period of time when noise might move a node into metastability. It's what Xilix calls the metastability-catching set-up time window. The time period during which noise might move a node out of metastability is typically much longer. This period is equal to the timing margin of your design, i.e. the difference between clock period and sum of the normal flip-flop delay, longest wire delay, combinatorial logic delay and the setup time of the next flip-flop. In the other words, the difference between actual clock period and the shortest possible clock period of the design. I have no experience in ASIC/Custom chip design, but when designing for FPGA I don't feel good when timing margin of my design is shorter then 500ps. According to Xilinx's estimation the duration of the metastability-catching set-up time window for their chips is 0.03 femtoseconds, i.e. 7 orders of magnitude shorter. So noise helps, I just don't know how much.Article: 49654
suchitra wrote: > hello all > I am programming XC9536 xl cpld using webpack's impact for the first time. > When i programme the cpld it doesnot give any error or warning. > But actually i am not achieving the functionality. > May be because of wrong pin assignment or some other problem. > Can any one of u guide me. Your problem description is vague enough that it's going to be hard for anyone to offer much help... but here it goes: 1. Why do you say you are not achieving the desired functionality? Are you just putting the part in the board and not seeing what you expect on a logic analyzer??? 2. Have you checked the fitter report (.rpt file) ? This file contains a lot of information about how the fitter fit your design, including pin assignments, and the logic equations created for each signal. Make sure everything is as you expect it to be. 3. Have you run a simulation? If not, you should. A starter version of ModelSim is available with Webpack. Create a VHDL or Verilog testbench to exercise your design, and run the Post-Fit simulation process in iSE. If you are not familiar with writing HDL testbenches, take a look at some of our examples (found in <XILINX>/iseExamples) or use TestBencher, which is an optional Webpack tool that allow you to graphically draw your stimulus and generate testbench code automatically. IF the fitter report looks good AND the Post-Fit simulation looks good, then most likely the part is not getting programmed correctly. I'm not very knowledgable about that end of things, so I would suggest contacting support.xilinx.com. -Dennis McCrohan Xilinx CPLD S/W Development.Article: 49655
On 18 Nov 2002 14:46:30 -0800, already5chosen@yahoo.com (Michael S) wrote: >Bob Perlman <bobsrefusebin@hotmail.com> wrote in message news:<q80ituogem7vbhnoard9tm0bdlalsa84ev@4ax.com>... >> On 18 Nov 2002 06:43:15 -0800, already5chosen@yahoo.com (Michael S) >> wrote: >> >> >I never studied the theory of metastable flip-flops. But intuitively I >> >see metastable state as a very small local minimum on the energy >> >curve. At the higher temperature the thermal noise can be strong >> >enough to rescue the flip-flop out of this state to the stable one. >> >It's all my speculations, may be, I erroneously apply the lows of >> >microworld lows to the macroworld phenomenon ? >> >> Back when the phenomenon of metastability was first observed and >> discussed, some people suggested that metastable behavior could be >> circumvented, or at least improved, by injecting noise that would move >> the offending device away from its metastable point. But others >> pointed out that while noise might move a node out of metastability, >> it was equally likely that noise would move an almost-metastable node >> into metastability. >> >> Bob Perlman >> Cambrian Design Works > > >I feel those "others" were wrong. OK. Good luck. Bob Perlman Cambrian Design WorksArticle: 49656
Where did you find the FPGA implementation? Is it in ABEL? If you the info you've found so far, I may convert to VHDL since this is some interest to me as well. "DarkDawn" <darkdawn@freemail.gr> wrote in message news:arb3v8$aht$1@nic.grnet.gr... > Hi all, > > I have already found some resources about FPGA implementation of MD5 hash > algorithm, but I couldn't find any VHDL source code. Could anyone please > help me? > > Thanks in advance for any assistance, > Antonis. > > >Article: 49657
Statements within a 'process' execute Sequentially , not Concurrently.. "when-else" , "with-select-when" are concurrent statements..."if-then-else" , "case-when" are sequential statements.. Pradeep "Anup Raghavan" <anup@itee.uq.edu.au> wrote in message news:9d80c593.0211121820.e951e8d@posting.google.com... | Hello, when i try to synthesize the following code using Leonardo | Spectrum for Xilinx FPGAs, I get errors " Syntax Error near 'when' " | If I dont use a process and then synthesize this code, it works fine. | But I do need to have a process in my design. Can someone provide me a | solution for this. | | Thanks | Anup Raghavan | | entity mux_tbuf is | | port (SEL: in STD_LOGIC_VECTOR (4 downto 0); | A,B,C,D,E: in STD_LOGIC; | clk : in std_logic; | SIG: out STD_LOGIC); | end mux_tbuf; | | architecture RTL of mux_tbuf is | begin | | sync: process (clk) is | | begin | if clk'event and clk = '1' then | sig <= A when sel = "11110" else 'Z'; | sig <= B when sel = "11101" else 'Z'; | sig <= C when sel(2)= '1' else 'Z'; | sig <= D when sel(3)= '1' else 'Z'; | sig <= E when sel(4)= '1' else 'Z'; | end if; | | end process sync; | | end RTL;Article: 49658
I am just trying to get these concepts straight in my mind.
If I clock data our of a ram (say block ram in a Spartan) this data is
available on the rising edge after the address is set up.
Can I use that data in a process that is clocked of the same rising edge?
Say I have
BLOCK_RAM myram(clk, address, dataout )
am I correct to say
always @(posedge clk){
case data
....
Will 'data' ever be in intermediate states? What about a propagation delay
where the clock edge arrives before the data? Would you always have to use
to cycles to do this (meaning that your data is 3 cycles behind the address
output)?
While I am here ( and this is really driving the questions ) I am trying to
get this simple cpu to run. When I synthise it can't infer block ram from
the ram declaration - short of actually declaring a block ram using the
xlinx primitive is there any way to get it to do that? Any other comments
about the below code are greatly appreciated also
module top();
reg clk;
wire [7:0] A;
ultra u1(clk,A);
always
begin
clk=0; #1
clk=0;#1
end
endmodule
module ultra(clk,A);
input clk;
output A;
reg [7:0] PC, MA;
reg [7:0] A, IR, MD;
reg [7:0] MEM[0:63]; // 64 words of 8-bit memory
reg [1:0] state; //0 INS Fetch
wire [5:0] imm = IR[5:0];
wire [1:0] ins = IR[7:6];
reg [1:0] icur;
reg we;
/*
00 LOAD M loads the contents of memory word M into the accumulator.
01 STORE M stores the contents of the accumulator in memory word M.
10 ADD M adds the contents of memory word M to the contents of the
accumulator.
11 JUMP M jumps to location M in memory.
Address Contents
0 Load 4
1 Add 5
2 Store 6
3 Jump 1
4 Data 1
5 Data 2
*/
initial begin
MEM[0]=8'h04;
MEM[1]=8'h85;
MEM[2]=8'h46;
MEM[3]=8'hc1;
MEM[4]=8'h01;
MEM[5]=8'h02;
end
always @(posedge clk)
begin
if ( we ) begin
MEM[MD] <= A;
we <= 0; end
else
IR <= MEM[MD];
case (state)
2'b00:
PC<=PC+1; ///Ins fetch
2'b01:begin
MD<=imm; //Decode
icur<=ins; end
2'b10: //execute
case (icur)
2'b00: A<=IR;
2'b01: we<=1;
2'b10: A <= A + {2'b00,imm};
2'b11: PC<= {2'b00,imm};
default:;
endcase
2'b11: MD<=PC;
default:;
endcase
state=state+1;
end
endmodule
Thanks
Ralph
Article: 49659Jim Granville <jim.granville@designtools.co.nz> wrote: >> Like a switching FF, it will take some time to go to a stable state. But it >> can be just close enough to the perfect balance point that it might take >> a while to move off center. The closer to the balance point, the longer >> it can take, so there is no maximum metastable time. > I'm not sure this assertion can apply forever. An infintite metastable state will occur with a 1/infinity probability :) >See Peter A's notes on metastable times, that >reflected to very narrow time windows, and working that to a >Wave-transit time, you get less than the order of a gate-length. > > Given this extremely short physical equivalence, it opens the idea of >a triple register, using traces as delay lines, and then taking a vote >of the outputs on the basis that all 3 cannot have the same metastable >lifetimes. It doesn't buy you anything, the one in the 'middle' will go metastable with the same probability as a single flipflop.Article: 49660
hmurray@suespammers.org (Hal Murray) wrote: >>I have tried to analyze the behaviour of such an analogy in the presence >>of noise, but I don't have the tools to do it rigorously. It may well >>be possible to shorten the metastable time with noise, but I really >>can't prove it one way or the other. > >Somebody mentioned noise recently, but I'll repeat. It doesn't work. >It kicks the system toward the stable point just as often as it helps >you by kicking the system in the right direction. It depends where the noise is. Yes noise on the input signal makes no difference. Noise (or preferably a well defined high frequency 'agitation') in the flipflop feedback path would limit the duration of the metastable state.Article: 49661
>> Given this extremely short physical equivalence, it opens the idea of >>a triple register, using traces as delay lines, and then taking a vote >>of the outputs on the basis that all 3 cannot have the same metastable >>lifetimes. > >It doesn't buy you anything, the one in the 'middle' will go metastable >with the same probability as a single flipflop. Actually, it's worst than the 1 FF case. The prop time through the voting logic gets subtracted from the settling time. You are much better off with that time in an exponent. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 49662
nospam wrote: > > Jim Granville <jim.granville@designtools.co.nz> wrote: > > >> Like a switching FF, it will take some time to go to a stable state. But it > >> can be just close enough to the perfect balance point that it might take > >> a while to move off center. The closer to the balance point, the longer > >> it can take, so there is no maximum metastable time. > > > I'm not sure this assertion can apply forever. > > An infintite metastable state will occur with a 1/infinity probability :) That's a mathematician's answer, and is the standard 'party line'. A quantum-physicist's analysis is what I would like to see :) > >See Peter A's notes on metastable times, that > >reflected to very narrow time windows, and working that to a > >Wave-transit time, you get less than the order of a gate-length. > > > > Given this extremely short physical equivalence, it opens the idea of > >a triple register, using traces as delay lines, and then taking a vote > >of the outputs on the basis that all 3 cannot have the same metastable > >lifetimes. > > It doesn't buy you anything, the one in the 'middle' will go metastable > with the same probability as a single flipflop. Looking at it closer, you are right. You can (slightly) reduce the probability with voting, but cannot avoid a 'just under vote' becomming 'just over vote' after the metastable delay, and so cannot force a MAX value on the metastable time. Simpler/better results can be got with opposite edge cascaded registers. -jgArticle: 49663
Stefan Kulke <kulke@informatik.tu-cottbus.de> wrote in message news:<arapdo$1i5$1@Maust.bbone.tu-cottbus.de>... > Hello, > > I should like to create a simple example for using a clkdll on Spartan 2 > XC2S200 with a Expansionboard (with LEDs and Pushbuttons). > I have created a circuit without DLL. This works correctly. The > clockspeed is 48 Mhz. > The circuit with clkdll, ibufg, bufg etc. doesn't work correctly. > It seems to be, the clk2x (clkdll) dont generate a clock signal. > > > I work with XILINX 4.2WP3. My toplevel circuit is a schematic, which > was created with Xilinx ECS. > There are an 16bit counter (with control logic) and an interface circuit > (for the expansion board). > The Clock from the counter should be the double frequency (96 Mhz). > > Now i try to explain my schematic: > > Pin GCK (p80)-> IBUFG -> CLKIN from CLKDLL -> CLK0 from CLKDLL -> BUFG > -> CLKFB from CLKDLL > > CLK2x from CLKDLL -> BUFG -> CLK-Input from Counter. > GND -> Reset from CLKDLL > > Constraint Implentation Editor: > The conduction (from CLK2x to BUFG) is identified as an clock net. > > I will be glad, if anybody tell me, where is my mistake in the design. > > with kind regards > > Stefan Usage of DLLs in a design is subject to certain location constraints, that is only a specific BUFG/DLL is associated with a particular GCLK pin, and this needs to be specified with a LOC constraint. Refer to foll. PDF for more info - http://direct.xilinx.com/bvdocs/publications/ds001_2.pdf Hope this helps, Vikram.Article: 49664
In article <3DD9A24F.766D@designtools.co.nz>, Jim Granville <jim.granville@designtools.co.nz> wrote: >> An infintite metastable state will occur with a 1/infinity probability :) > >That's a mathematician's answer, and is the standard 'party line'. > >A quantum-physicist's analysis is what I would like to see :) I'd bet that a quantum physicist would say "quantized noise makes it shorter". But thats just a Wild Ass Guess. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 49665
Michael S wrote: > > I feel those "others" were wrong. > There is relatively short period of time when noise might move a node > into metastability. It's what Xilix calls the metastability-catching > set-up time window. > The time period during which noise might move a node out of > metastability is typically much longer. This period is equal to the > timing margin of your design, i.e. the difference between clock period > and sum of the normal flip-flop delay, longest wire delay, > combinatorial logic delay and the setup time of the next flip-flop. In > the other words, the difference between actual clock period and the > shortest possible clock period of the design. We call that slack time, the difference between the time allowed for a given clock controlled path and the actual time needed. > I have no experience in ASIC/Custom chip design, but when designing > for FPGA I don't feel good when timing margin of my design is shorter > then 500ps. According to Xilinx's estimation the duration of the > metastability-catching set-up time window for their chips is 0.03 > femtoseconds, i.e. 7 orders of magnitude shorter. How is the metastable timing window related to the timing slack? The time window is the period in time where the input must be in the undefined region of voltage to end up with a metastable internal state that lasts long enough to affect the settling time. The timing slack is the amount of extra time that is available for the output to settle before it affects any FFs connected to the metastable output. These are two different and unrelated aspects of metastability. > So noise helps, I just don't know how much. I don't agree with your analysis, because you make an *assumption* about the initial conditions which can lead to metastability, but that is not the real issue. The real issue that the knowledge of noise reducing the metastability settling time is not useful information. To be able to use noise as a tool, you would have to provide a minimum noise spec. How can a spec be generated of the required spectral characteristics of the noise to reduce metastable failures? I think that if you try to answer that question, you will see why noise does, in fact, *not* improve metastability recovery times. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 49666
Hal Murray wrote: > > > Given this extremely short physical equivalence, it opens the idea of > >a triple register, using traces as delay lines, and then taking a vote > >of the outputs on the basis that all 3 cannot have the same metastable > >lifetimes. > > That sounds like one of the kludges I was talking about. > > What do you do if one path says 0, the other says 1, and the third > goes metastable? How do you know that one is metastable? Have you developed a metastable detector? ;^) > You can't "fix" metastability. Get suspicious when somebody tries, > or appears to be trying. It means they don't understand it. > > As Peter often says, you can make things good enough, especially > with modern silicon. But the basic mechanism is still exponential > decay. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 49667
Jim Granville wrote: > > nospam wrote: > > > > Jim Granville <jim.granville@designtools.co.nz> wrote: > > > > >> Like a switching FF, it will take some time to go to a stable state. But it > > >> can be just close enough to the perfect balance point that it might take > > >> a while to move off center. The closer to the balance point, the longer > > >> it can take, so there is no maximum metastable time. > > > > > I'm not sure this assertion can apply forever. > > > > An infintite metastable state will occur with a 1/infinity probability :) > > That's a mathematician's answer, and is the standard 'party line'. > > A quantum-physicist's analysis is what I would like to see :) There you go looking for trouble. If you know anything about quantum mechanics you would realize that he/she would say that the FF can exist in *both* stable states at once!!! How are you going to analyze that?? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 49668
nospam wrote: > > hmurray@suespammers.org (Hal Murray) wrote: > > >>I have tried to analyze the behaviour of such an analogy in the presence > >>of noise, but I don't have the tools to do it rigorously. It may well > >>be possible to shorten the metastable time with noise, but I really > >>can't prove it one way or the other. > > > >Somebody mentioned noise recently, but I'll repeat. It doesn't work. > >It kicks the system toward the stable point just as often as it helps > >you by kicking the system in the right direction. > > It depends where the noise is. Yes noise on the input signal makes no > difference. Noise (or preferably a well defined high frequency 'agitation') > in the flipflop feedback path would limit the duration of the metastable > state. I feel bad now. I started this thread because I had hoped to get some definitive information to take back to a discussion that was hot in comp.lang.forth a few days ago. I had some people over there telling me that they could "cure" metastability or that it was dealt with in the chips. There was even one chip designer who told me that you could safely "ignore" metastability in modern logic (modern being anything smaller than 0.25 um) because of the high settling speeds. Now it looks like the FPGA people here can't even agree among themselves!!! Maybe I need to ask the people in comp.arch.embedded? ;^) -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 49669
Hi - I was searching Google for the words "metastability" and "noise." and came across an interesting MIT course presentation that I'd commend to anyone new to the topic. The presentation, part of a Computing Structures course, can be found at: http://6004.lcs.mit.edu/Fall01/handouts/L08-1up.pdf One of the foils has an interesting, abbreviated history of metastability, which I've reproduced below: ===== The Metastable State: a brief history Antiquity: Early recognition - Buriden’s Ass, and other fables… Denial: Early 70s - Widespread disbelief. Early analyses documenting inevitability of problem rejected by skeptical journal editors. Folk Cures: 70s-80s - Popular pastime: Concoct a “Cure” for the problem of “synchronization failure”. Commercial synchronizer products. Reconciliation: 80s-90s - Acceptance of the reality: synchronization takes time. Interesting special case solutions. ===== If you lived through this, you know that it's absolutely on target. Apparently, we're in the midst of a 70's revival. I guess I can put up with it, as long as David Cassidy doesn't make a comeback. Bob Perlman Cambrian Design WorksArticle: 49670
> If I clock data our of a ram (say block ram in a Spartan) this data is
> available on the rising edge after the address is set up.
Yes, after a few ns. ( A few ns after the rising edge)
>
> Can I use that data in a process that is clocked of the same rising edge?
I don't think so, in the manner you imply. The data becomes valid sometime
after the clock edge used to register the address of the ram. This is just
like the output of a ff. You cannot use the output of that ff as valid data
for input of other logic which is clocked on that very same rising edge. You
have to wait for the next rising edge.
> am I correct to say
>
> always @(posedge clk){
> case data
> ....
>
Yes, but remember the 'data' from the ram acts just like the output of a ff.
So the data will have to have been made valid as a result of the previous
clk edge (ie sometime after the previous clk - before this one).
> Will 'data' ever be in intermediate states? What about a propagation delay
> where the clock edge arrives before the data? Would you always have to use
> to cycles to do this (meaning that your data is 3 cycles behind the
address
> output)?
>
Yes, the data is 'behind' the address input, but only by a single cycle. If
your address becomes valid sometime after the clock edge of one cycle, then
the data from the bram becomes valid sometime after the next clock edge. So
it looks like <clk edge> <address being made available during this clock>
<clk edge> < data being made available during this clk>
It is a standard synchrounous approach. The ram acts just like a ff except
it has a few more ns delay. (It has a longer clk to valid output time)
> While I am here ( and this is really driving the questions ) I am trying
to
> get this simple cpu to run. When I synthise it can't infer block ram
from
> the ram declaration - short of actually declaring a block ram using the
> xlinx primitive is there any way to get it to do that? Any other comments
> about the below code are greatly appreciated also
>
It's possible to infer a block ram, but to do so the address inputs of the
ram must be registered by a clock edge. I ususally do this both ways. For
simulation I use an inferred block ram, but for synthesis I use the
primitive to make it easier to set the initial contents of the ram.
> always @(posedge clk)
> begin
>
> if ( we ) begin
> MEM[MD] <= A;
> we <= 0; end
> else
> IR <= MEM[MD];
Unfortunately it can't be done this way and infer a block ram. What's
appears to be inferred in this case is an asynchronous ram, probably
constructed out of LUT resources. In order to get an inferred block ram, it
has to look something like:
module....
reg [3:0] memAddr;
// register the address input to the memory in order to infer a block ram
always @(posedge clk) begin
memAddr <= MD;
if ( we )
MEM[memAddr] <= A;
IR <= MEM[memAddr];
end
Putting it in it's own module would be good, because then the code can be
reused, and it might make it easier for the synthesizer to synthesize a
bram.
There are a couple of simple ways of working around this characteristic of
bram if you want to emulate an asynchronous ram. 1) Use two clock cycles and
alternate between the two. One to setup the address and the next to access
the ram. Or 2) clock the ram on the negative edge of the clock while the
rest of the design works on the positive edge. (Effectively cuts the
performance of the design in half. Or 3) (this is a method I use alot)
create (outside of clocked logic) a 'next address' signal that represents
what the next address would be after the clock edge, and feed that into the
address input for the bram. so rather than using MD use MD_nxt, where MD <=
MD_nxt after the clock edge.
Other than that, you have to look into pipelining the design which is a good
way of obtaining performance and works very well in an FPGA.
Rob
www.birdcomputer.ca
Article: 49671
Hi,
I am trying to instantiate embedded MULT18X18 signed multiplier in
Xilinx foundation 3.1i series. While implementing the design on
XCV100E-8-PQ240, I am getting the following error:
ERROR:NgdBuild:432 - logical block 'M1' with type 'MULT18X18' is
unexpanded
I noticed that libraries getting attached to the project are : Virtex
and Simprim, I tried to change the library to virtex II ( It contains
MULT18X18). But while implementing, the library, automatically, got
changed to virtex.
Can you please give me the direction regarding this? It will help me
to go ahead in my project.
I tried to generate multiplier core from Logicore, I found that the
timing analysis (delay) for pipelined and non pipelined multiplier is
same. I am wondering if core uses internal pipelined register while
generating pipelined multiplier.
thanks in advance,
-Jyoti
Article: 49672
Where slack does come into play with metastability is that your
metastability resolution time available is equal to the slack time. If your
path leading from your syncronizer has little slack, your chances of a
metastable event lasting long enough to matter is greatly increased. You
want to maximize the slack after a synchronizer, preferably with
geographically close registers with no intervening logic.
rickman wrote:
stuff about slack time not being related to metastability
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 49673Also, both the write-enable and the enable need to be asserted, with setup and hold wrt the rising edge. -Stan "Peng Cong" <pc_dragon@sohu.com> wrote in message news:ar9g3e$1vjj$1@mail.cn99.com... > ModelSim support Block RAM simulation, I just use it now. > Check you write enble signal if the data write into block ram really. > > "Lorenzo Lutti" <lorenzo.lutti@DOHtiscalinet.it> дÈëÏûÏ¢ÐÂÎÅ > :1NVB9.43841$8E3.1278377@twister2.libero.it... > > This question is likely very trivial, but I haven't found the answer in > > any FAQ. I'm developing a ISE project for a Spartan II device; when I > > simulate it with ModelSim (I use the post-place&route model) the values > > stored in block RAM during the simulation aren't retained, and if I read > > back the same locations I apparently just get the initialization values. > > > > Is this correct? I hope it's just my mistake. :) > > > > -- > > Lorenzo > > > > > >Article: 49674
First, you need to go back and revisit the data sheet. I believe you will find a
minimum DLL input clock frequency of 25 MHz there. It will work at lower
frequencies, but is not guaranteed over voltage, temperature and process...in other
words if you put this into production I guarantee you'll have failures.
Xilinx originally said that it was safe to go directly between the clock domains,
however experience dictates otherwise. If the DLL output jitter plus intrinsic
clock tree skew in the part are less than the minimum propagation time between the
registers, then you are OK. Since there is no minimum propagation time specified,
you already have a problem if there is *any* jitter, but practically speaking there
is a minimum prop time. For a jitter-free clock coming in, and matched clock
distribution, you can go directly between....but: The incoming clock jitter is
seldom small, and if you have single ended outputs on the same bank as the clock
you can introduce considerable jitter on the clock through threshold modulation due
to switching I/O. Also, the clock distribution is not closely matched unless you
load each very similarly in each column (you'd have to do this by hand, as the
placer won't even come close). We saw this happen soon after Virtex first came
out.
Instead, I recommend that you be very careful about how you transfer data across
the 1x/2x clock boundaries, as the edge can fluctuate by several hundred ns
relative to the edge in the other domain...enough to cause mis-clocking. Positive
edge to negative edge should be fine
louis wrote:
> There's a external clock input (20MHz) on my system, and I multiply
> it to 2X (40MHz) by DLL as the working clock.
> However, I have to exchange data in several
> modules between these two clock domains. I don't know if it safe to sample data
> on both positive edges of these two clocks?
> Will the clock jitter cause the metastability? Or I have to generate data
> on positive edge and retrieve data on negative edge instead?
> The target chip is SpartanIIE. Any comment and suggestion will be very
> appreciated.
>
> louis
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
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