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
"Tim" <tim@rockylogic.com.nospam.com> wrote:
> There may be an 'official' way, but I have always ended up
> instantiating the LUT.
>
> Which is not too difficult in VHDL but, AFAIK, tricky in Verilog.
>
This is what I ended up doing. I guess the Golden Age of high level
HDL hasn't arrived yet. The sad thing is that everyone thinks it has,
so when I write something simple, the tool trys to second guess me and
make an "optimization". I have to go to great effort to tell it to
just fucking do what I say. Instantiating a LUT is to HDL programming
as instantiating machine op-codes is to C programming.
Here's how to instantiate a LUT in Synplicity/Verilog:
LUT3 #('h2f) shift0(Shift[0], Sending, Stall, Ready);
Unfortunately, not all synthesis/simulation tools accept
the same format.
> "Don Husby" <husby_d@yahoo.com> wrote in message
> news:35802095.0109181335.38d1e3a1@posting.google.com...
> > How do I prevent Synplify from optimizing away my
> > attempts to replicate logic?
> >
> > For the following code, synplify will merge the two instances
> > of Shift into the same net:
> >
> > wire [1:0] Shift /* synthesis syn_keep=1 */;
> > assign Shift[0]= Sending & !Stall | !Ready; //
> > assign Shift[1]= Sending & !Stall | !Ready; // Replicated
> >
> > Also, is there some way to get synplify to print a message when
> > it encounters an attribute? Otherwise, there's no way to tell
> > if the attribute has an error that causes it to not be recognized
> > as an attribute.
Article: 35101Has anyone seen noisy outputs in an Altera 20KE series device during bus switching? I have an output control signal located in a bank that drives a wide bus (32 bits). When all bits of the bus change at the same time, the control signal glitches. I'm trying to isolate the problem between the circuit board layout and the Altera FPGA device. Thanks.Article: 35102
I'm using a Xilinx XC95216-PQ160 CPLD and the fitter 'hitop' gives me the following warning : WARNING:hi434 - We have detected that a large number of internal signals may be switching at the same time. To avoid potential simultaneous switching/ground bounce issues, please contact Xilinx customer support for more information. Does anybody have any experience with this message? The design seems to work correctly, I'm using a multilayer PCB, the programmable GND pins and a 100nF Capacitor at every supply pin, but I would like to know if there are some potential problems. Thank you very much. -- Falser Klaus R&D Electronics Department Company : Durst Phototechnik AG Vittorio Veneto Str. 59 I-39042 Brixen Voice : +0472/810235 : +0472/810111 FAX : +0472/830980 Email : kfalser@IHATESPAMdurst.itArticle: 35103
Hi Philip : I completely agree with you. Unfortunately, I can not avoid ASYNC signals in my current work. However, my experience about estimated routing delay from Xilinx or Altera design tools is not bad. Their estimation is reasonably well. (at least at room tempature). Thanks for your comments. regards, LIN CH "Philip Freidin" <philip@fliptronics.com> wrote in message news:0h3lqtgblji4gaha6o8th40l9srt72ncg1@4ax.com... > > I hope you understand that all the delays reported by the timing analyzer > and the FPGA_Editor are worst case delays. You cannot get bestcase > or actual delays. > > So if you have two paths and the tools tell you the delays are 16nS and 20nS > adding 4 nS to the first one does not solve your problem because you > dont know what the actual delays are, only the worst values that they might be. > > For instance, the real delays might be 6 ns and 18ns. Adding 4 does not > match them. > > Or they might be both actually 14 nS. adding 4 stops them from being matched. > > Or any one of an infinite number of other possibilities. > > Without criticizing your design, when people ask about delay matching and > screwing around with routing to adjust timing for any reason other than meeting > a cycle time requirement, my thinking is that you may need to rethink your > design approach. > > Good luck, > > Philip Freidin > > On Wed, 19 Sep 2001 11:35:47 +0200, "Chih-Hsun Lin" <Chih-Hsun.Lin@cern.ch> > wrote: > >Hi : > >Thanks very much for your answer. > > > >Actually, my case is that two async signals come out from the same CLB to 2 > >output pads. > >I want the routing delay for those two signals shall be similar. The usual > >routing medthod > >is to get minimum delay. In order to match the routing delay, I think the > >easy way shall be > >increase routing dealy for one signal to match the other. However, I did not > >find a way to > >do it easily in FPGA editor. > > > >Best regards, > >Lin CH > > > > Philip Freidin > FliptronicsArticle: 35104
Is anybody who can help me with PCI-32 implementation for Spartan-2? Please contact by E-mail 'nanko@nanko.ru', subject: "for Alexander Kurbasov". Many thanks!!Article: 35105
Hi everybody I try to control the programming of a Xilinx 9500 CPLD from an application. For this I need a CPLD-programmer and a software (exe or dll) which must be controllable by my application. e.g. I want to check if the CPLD is erased, erase a CPLD, program the CPLD and make a verify of the downloaded code. One of the possible solution may be that I call the programming software with command line parameters and then get the exit code of the program to return the status of the operation back to the calling application. Another solution may be that there is an ActiveX-Control or DLL available to handle the communication with the programmer. To program the CPLD I have either the JED file or the SVF file. => Does anyone know about a programmer which is "remote" controllable as described? I have already looked at the JAM-Player from Altera, but XILINX seems not to support the JAM format directly. If I convert a XILINX SVF file with the Altera tool svf2jam the file grows from 2MB to 6MB (the JED file is only 200k bytes!). Also I could not find examples of DO_ERASE, DO_BLANKCHECK, DO_SECURE procedures implemented in JAM for a XILINX 9500 CPLD. => Does anybody know about a JAM composer for XILINX 9500 CPLD's? Thanks BrunoArticle: 35106
if you have a large number of signals on the bus changing state simultaenously then you might run into ground bounce issues, especially if the physical layout is using the same IO bank and/or there is not enough de-coupling on the supply pins. refer to the Quartus and APEX pins assignment guidelines in one of the Altera App Notes. Ahmed. On Fri, 21 Sep 2001 04:36:55 GMT, "Dave Barry" <davebarry@home.com> wrote: > Has anyone seen noisy outputs in an Altera 20KE series device during bus > switching? I have an output control signal located in a bank that drives a > wide bus (32 bits). When all bits of the bus change at the same time, the > control signal glitches. I'm trying to isolate the problem between the > circuit board layout and the Altera FPGA device. > > Thanks. > >Article: 35107
Hello everyone, I searched for answer to the above in several fpga faqs, but came up empty. My project is about taking multiple sensor readings, doing some heavy math involving PCA, matrices and waveform analysis, then controlling some small dc motors in near-real time (soft). There are also requirements for some wireless I/O and flash disk storage. My primary constraint is the cost to develop a prototype considering my limited experience with FPGAs. The solution offered by Celoxica is interesting (www.celoxica.com) since I get to stay in my comfort zone of just writing C without having to learn everything about FPGAs. Thanks in advance for your helpful advice, JeffArticle: 35108
With synplicity, if you put the logic for the lut in a separate component and put
the synplify xc_map attribute on it, it does essentially what fmaps used to do in
schematics. That way, you get the benefits of lut instantiation (you can even put
an RLOC on the instantiation) without the peril associated with getting the right
init string into the LUT. For example, the following code is a 2 input OR that
can be instantiated, RLOC'd etc, and it doesn't disolve at the whim of the tools:
--FMAP'd or2
library IEEE;
use IEEE.std_logic_1164.all;
entity fmap_or2 is
port ( a, b : in std_logic;
z : out std_logic);
end fmap_or2;
architecture rtl of fmap_or2 is
attribute xc_map : STRING;
attribute xc_map of rtl : architecture is "lut";
begin
z <= a or b;
end rtl;
Don Husby wrote:
> "Tim" <tim@rockylogic.com.nospam.com> wrote:
> > There may be an 'official' way, but I have always ended up
> > instantiating the LUT.
> >
> > Which is not too difficult in VHDL but, AFAIK, tricky in Verilog.
> >
>
> This is what I ended up doing. I guess the Golden Age of high level
> HDL hasn't arrived yet. The sad thing is that everyone thinks it has,
> so when I write something simple, the tool trys to second guess me and
> make an "optimization". I have to go to great effort to tell it to
> just fucking do what I say. Instantiating a LUT is to HDL programming
> as instantiating machine op-codes is to C programming.
>
> Here's how to instantiate a LUT in Synplicity/Verilog:
>
> LUT3 #('h2f) shift0(Shift[0], Sending, Stall, Ready);
>
> Unfortunately, not all synthesis/simulation tools accept
> the same format.
>
> > "Don Husby" <husby_d@yahoo.com> wrote in message
> > news:35802095.0109181335.38d1e3a1@posting.google.com...
> > > How do I prevent Synplify from optimizing away my
> > > attempts to replicate logic?
> > >
> > > For the following code, synplify will merge the two instances
> > > of Shift into the same net:
> > >
> > > wire [1:0] Shift /* synthesis syn_keep=1 */;
> > > assign Shift[0]= Sending & !Stall | !Ready; //
> > > assign Shift[1]= Sending & !Stall | !Ready; // Replicated
> > >
> > > Also, is there some way to get synplify to print a message when
> > > it encounters an attribute? Otherwise, there's no way to tell
> > > if the attribute has an error that causes it to not be recognized
> > > as an attribute.
--
--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: 35109
Even with async signals, you design should be done so that the signal delay is
not critical to circuit operation. That requires correct hazard analysis for
both static and dynamic hazards.
From my experience, the xilinx delays reported by the tools are usually about
40-50% pessimistic at room temperature. If the delay values were fairly
accurate at room temperature like you state, designs meeting timing in the
timing analyzer would fail at even slightly elevated temperatures. The delays
reported are worst case over temperature, supply voltage, and process
variations.
I am with Philip, if you are trying to match delays, you probably need to
rethink your design. If you do have truely async stuff, you need to look
carefully at async design techniques, and you will probably have to instantiate
luts or use keep buffers to keep your cover terms from being optimized out.
Chih-Hsun Lin wrote:
> Hi Philip :
> I completely agree with you. Unfortunately, I can not avoid ASYNC signals in
> my current work. However, my experience about estimated routing delay from
> Xilinx or Altera design tools is not bad. Their estimation is reasonably
> well.
> (at least at room tempature).
>
> Thanks for your comments.
>
> regards,
> LIN CH
>
> "Philip Freidin" <philip@fliptronics.com> wrote in message
> news:0h3lqtgblji4gaha6o8th40l9srt72ncg1@4ax.com...
> >
> > I hope you understand that all the delays reported by the timing analyzer
> > and the FPGA_Editor are worst case delays. You cannot get bestcase
> > or actual delays.
> >
> > So if you have two paths and the tools tell you the delays are 16nS and
> 20nS
> > adding 4 nS to the first one does not solve your problem because you
> > dont know what the actual delays are, only the worst values that they
> might be.
> >
> > For instance, the real delays might be 6 ns and 18ns. Adding 4 does not
> > match them.
> >
> > Or they might be both actually 14 nS. adding 4 stops them from being
> matched.
> >
> > Or any one of an infinite number of other possibilities.
> >
> > Without criticizing your design, when people ask about delay matching and
> > screwing around with routing to adjust timing for any reason other than
> meeting
> > a cycle time requirement, my thinking is that you may need to rethink your
> > design approach.
> >
> > Good luck,
> >
> > Philip Freidin
> >
> > On Wed, 19 Sep 2001 11:35:47 +0200, "Chih-Hsun Lin"
> <Chih-Hsun.Lin@cern.ch>
> > wrote:
> > >Hi :
> > >Thanks very much for your answer.
> > >
> > >Actually, my case is that two async signals come out from the same CLB to
> 2
> > >output pads.
> > >I want the routing delay for those two signals shall be similar. The
> usual
> > >routing medthod
> > >is to get minimum delay. In order to match the routing delay, I think the
> > >easy way shall be
> > >increase routing dealy for one signal to match the other. However, I did
> not
> > >find a way to
> > >do it easily in FPGA editor.
> > >
> > >Best regards,
> > >Lin CH
> > >
> >
> > Philip Freidin
> > Fliptronics
--
--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: 35110John_H, My comments below.... Austin John_H wrote: > questions below: > > Austin Lesea wrote: > > > John_H wrote: > > > >> How long (if at all) does it take to settle from this > >> delay-line-switched > >> phase change? > > > > It takes 84 clocks on the CLKIN input, plus three on the PSCLK input > > to effect a change (increment or decrement). If those are tied > > together (commonly done) that is 87 clocks. You MUST wait for PSDONE > > before PSEN is asserted to inc or dec again. > > 87 clocks to move 1/256 cycle (on average) gives 45ppm of frequency > adjustment capability if continuous phase adjustment is achieved - > disappointingly slow. If I could directly control the phase value > directly (best choice), inc/dec by more than 1/256, or have the change > occur sooner (15 clocks?) the usability of the DCM increases > significantly. Yup. No doubt about it. +/- 45 ppm is just twice shy of where it would get really interesting. Thanks for confirming our math, '45' is the number we get as well. > > > >> Can the phase shift be "wrapped around" such that decrementing > >> past -255 > >> ends up back at zero? > > > > No. The phase shift increments until it overflows (sticks at 255), or > > decrements until 0 (then sticks at 0). An external counter is > > required if you want to keep track of it. If you PSOVERFLOW, the unit > > needs a RESET to go again. > > Does the RESET do nasty things to the clock or is it a seamless > transition to zero phase? (I guess I'm grasping at straws) Nasty things. All outputs go to hard '0' If you want to do really neat things, contact you FAE for more subtle details of the DCM (re: freeze mode, test mode). > > > --- new question --- > > Can the BUFGMUX primitives be cascaded to allow selection of, say, 4 > clocks? More specifically, 4 clock phases from a DCM? I don't see why not. The BUFGMUX is a state machine, so it always requires the input clocks to be transistioning, or it will not switch. Again, in the future, a simple mux option would be nice, and we have recognized this.Article: 35111
Rick, It exactly the right place, as you state. That is why you have to be so very careful. If too many cycles go by, the DLL itself drifts, and then the same place isn't there any more. It is a lot like humming a tune on a CD, if you go away for too long, you are not in sync when you come back. In lab tests, we can interrupt the clock for periods of a few hundred microseconds in a quiet environment, and it does not lose lock, but that is pretty far from the real world. Austin Rick Filipkiewicz wrote: > It says in the Virtex-E databook that the the clock input to a DLL can > be stopped & restarted as long as the clock is stopped while its low. > > How does this square with the max cycle-to-cycle input variation > parameter of 1nsec. ? > > When the clock is re-started does this mean that the the first new > rising edge has to be in the same place +/- 1 nsec it would have been if > the clock had not been stopped ?Article: 35112
So there's a free-running clock inside the DLL? I thought the comparisons were for delayed clock versus live clock such that once the comparison edges are "lost" due to inactivity, the edge placement can be wherever; it's just the cycle time that's important at that point (which can easily drift). This capability could have direct impact on an upcoming design. Austin Lesea wrote: > Rick, > > It exactly the right place, as you state. That is why you have to be so > very careful. If too many cycles go by, the DLL itself drifts, and then the > same place isn't there any more. > > It is a lot like humming a tune on a CD, if you go away for too long, you > are not in sync when you come back. > > In lab tests, we can interrupt the clock for periods of a few hundred > microseconds in a quiet environment, and it does not lose lock, but that is > pretty far from the real world. > > AustinArticle: 35113
John_H, No there is not a free running clock. There is a delay line. The incoming edge stops happening. The delay line empties out. There is no CLKFB signal now. Now you start again. The CLKFB signal comes in again (some cyles later). When it does, it has to be in the window wrt to the CLKIN signal, or you lose lock. Austin John_H wrote: > So there's a free-running clock inside the DLL? I thought the comparisons were > for delayed clock versus live clock such that once the comparison edges are > "lost" due to inactivity, the edge placement can be wherever; it's just the > cycle time that's important at that point (which can easily drift). > > This capability could have direct impact on an upcoming design. > > Austin Lesea wrote: > > > Rick, > > > > It exactly the right place, as you state. That is why you have to be so > > very careful. If too many cycles go by, the DLL itself drifts, and then the > > same place isn't there any more. > > > > It is a lot like humming a tune on a CD, if you go away for too long, you > > are not in sync when you come back. > > > > In lab tests, we can interrupt the clock for periods of a few hundred > > microseconds in a quiet environment, and it does not lose lock, but that is > > pretty far from the real world. > > > > AustinArticle: 35114
It is possible to use the enable input on the global clock buffers. I think they work in the same way as the Virtex2 BUFGCE macro, its just that they are not supported by the current software (maybe for good reason ?). You would need to create a hard macro in Fpga Editor containing a GCLKBUF with the I, O and CE pins as external pins. You would also need a black-box VHDL component for your macro and since simulation is not supported a simple model as well. The odd thing is, to get it to work you need to set the GCLKBUF CEMUX to '1' (implying GCLKBUFs derived from a BUFG gate the clock with whatever is routed to the CE pin). To be safe, drive the CE pin from a FF clocked off the falling edge of the ungated clock. The P&R tools will treat the clock net as being un-gated. Virtex BUFGCEs might be supported in the new version 4 software - anyone ? -- Edward Moore Charles Ross <rossc@cs.colostate.edu> wrote in message news:<3BAA590B.FAF4E683@cs.colostate.edu>... > Im interested in making use of the clock enable pins > that exist in the Virtex CLBs. > > I have got a VHDL component, which expects a streams > of values to be entered in serial. However, the I/O > bandwidth of my board is not sufficient to supply the > stream. I would like to specify a value to be used as > the clock enable for the entire component. This way > I would be able to prepare one set of values, raise the > clock enable for just one clock cycle, then lower it > again while I prepare the next set of values. > > The VHDL component is behavioral, and computer generated. > So, I am unable to modify the code which generates it, or > I would have added a "data valid" signal to the component > This is unfortunatly not possible. It also contains > several other components, which I also cannot modify. > > I thought about using a gated clock, IE: > my_gated_clock <= CLK and my_clock_enable; > > And then using the gated clock to drive the clock of > the component, but this seems quite primitive, and > likly to cause clock scew, or other nasty problems. > I know that clock signals have dedicated resources > and it occured to me that using a gated clock would > cause the clock signal to be a regular signal, which > might cause problems. I am uneasy about messing with > the actual clock lines. > > I looked around in the synplify manuals and found > an attribute called "syn_direct_enable" which appears > to be for specifying a clock enable for a component, > but the description of the attribute is poor. I have > not been able to get it to work. > > If I am able to figure out how to easily make use of > the Clock enable I will be able to use them for other > "data valid" type signals to generate more efficient > code. > > Any suggestions? Examples?Article: 35115
Hi; I seem to remember seeing something along the lines of a synthesizable PCI bridge reference design on the Xilinx web site some time ago. Now I can't find it. Does anyone else remember this, or am I imagining things? The reason I ask is that I'm looking for a lightweight PCI testbench. There is a very simple one that comes with their PCI core for testing their "ping32" example design. I thought there might be one included with the PCI bridge reference design as well. Cheers, JamieArticle: 35116
Austin Lesea wrote: > Rick, > > It exactly the right place, as you state. That is why you have to be so > very careful. If too many cycles go by, the DLL itself drifts, and then the > same place isn't there any more. > > It is a lot like humming a tune on a CD, if you go away for too long, you > are not in sync when you come back. > > In lab tests, we can interrupt the clock for periods of a few hundred > microseconds in a quiet environment, and it does not lose lock, but that is > pretty far from the real world. > > Austin > > If I wanted to do this for longer & could figure out some ``refresh'' circuit what would a realistic, noisy real-world, min period be ? Clearly the best answer would be - use the clock mux on a V-2.Article: 35117
That's exactly what Celoxica wants you to think. If only it were true! -Kevin "Jeffrey Graham" <jgraham@lincom-asg.com> wrote in message news:3BAB4345.B33B3F86@lincom-asg.com... > Hello everyone, > > I searched for answer to the above in several fpga faqs, but came up empty. > > My project is about taking multiple sensor readings, doing some heavy > math involving PCA, matrices and waveform analysis, then controlling > some small dc motors in near-real time (soft). > > There are also requirements for some wireless I/O and flash disk storage. > > My primary constraint is the cost to develop a prototype considering my > limited experience with FPGAs. > > The solution offered by Celoxica is interesting (www.celoxica.com) since > I get to stay in my comfort zone of just writing C without having to learn > everything about FPGAs. > > Thanks in advance for your helpful advice, > Jeff >Article: 35118
Unfortunatly, this wont solve my problem.. Does anyone know if it possible to
specify a clock enable pin for EVERY clb in a component?
(Im using Synplify, and foundation tools 3.3ip8)
> You would need to create a hard macro in Fpga Editor containing a
> GCLKBUF with the I, O and CE pins as external pins. You would also
> need a black-box VHDL component for your macro and since simulation is
> not supported a simple model as well.
This sounds like a great one-time solution, but I wont be able to do this for each
and every computer generated VHDL component. (Of which there are a countless
number) the component itself, in VHDL is not alowed to change.
> Virtex BUFGCEs might be supported in the new version 4 software -
> anyone ?
Which software? Synplify? Foundation Tools?
--
_____ _____
___ | | __ |
|___| | --| -|
|_____|__|__|
Article: 35119Why not put the location constraints in the .UCF file? Makes the code more portable. --a Johan Ditmar wrote: > > Hello, > > I have a problem with pin location constraints using Verilog/FPGA express. > I have the following simple design: > > module test(A, B); > input A; //synopsys attribute LOC "P63" > output B; > > assign B=A; > > endmodule > > When I run synthesis and then place and route, the Xilinx PAR tools give the > following warning: > > WARNING:NgdBuild:483 - Attribute "LOC" on "N_A" is on the wrong type of > object. > Please see the "Attributes, Constraints, and Carry Logic" section of the > Libraries Guide for more information on this attribute. > > It turns out, that FPGA express puts the constraint on the output net of the > input buffer of A, in stead of A itself. > Does anyone know how to solve this from within Verilog? > > Kind Regards, > > JohanArticle: 35120
Very tedious to do too, esp if you have any regular structure in your design.
Putting the placement in the code allows you to build the structure hierarchically
instead of flat. You can floorplan even pretty big designs rather quickly that
way.
Of course, if it is just pin assignments you are worried about, I'd do that in the
UCF. I think it is easier (pins are flat anyway)
Andy Peters wrote:
> Why not put the location constraints in the .UCF file? Makes the code
> more portable.
>
> --a
>
> Johan Ditmar wrote:
> >
> > Hello,
> >
> > I have a problem with pin location constraints using Verilog/FPGA express.
> > I have the following simple design:
> >
> > module test(A, B);
> > input A; //synopsys attribute LOC "P63"
> > output B;
> >
> > assign B=A;
> >
> > endmodule
> >
> > When I run synthesis and then place and route, the Xilinx PAR tools give the
> > following warning:
> >
> > WARNING:NgdBuild:483 - Attribute "LOC" on "N_A" is on the wrong type of
> > object.
> > Please see the "Attributes, Constraints, and Carry Logic" section of the
> > Libraries Guide for more information on this attribute.
> >
> > It turns out, that FPGA express puts the constraint on the output net of the
> > input buffer of A, in stead of A itself.
> > Does anyone know how to solve this from within Verilog?
> >
> > Kind Regards,
> >
> > Johan
--
--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: 35121I sincerely appreciate your insight and assistance in this newsgroup. You and Peter Alfke are great resources to help pass along these Xilinx details to people who need them. So please see my continuing desire to understand in a positive light :-) When there is no clock activity, there is no CLKFB and there is no CLKIN for the Xilinx DLL. Since the DLL was "trained" earlier by a clock that caused the DLL to choose a delay tap, the delay is set and fixed (for now). When the clock starts up again, the CLKIN has an edge but CLKFB is absent. Once CLKIN propagates through the delay line, CLKFB will be present and (if CLKIN has the same period it had before) the phases will match. The only "window" is CLKIN relative to CLKFB. So if a clock has been absent long enough for CLKFB to flatline, the new phase alignment is arbitrary. If the above sequence of events doesn't describe the operation, what is the window referenced to? - John Austin Lesea wrote: > John_H, > > No there is not a free running clock. There is a delay line. > > The incoming edge stops happening. The delay line empties out. > > There is no CLKFB signal now. > > Now you start again. The CLKFB signal comes in again (some cyles later). When it > does, it has to be in the window wrt to the CLKIN signal, or you lose lock. > > AustinArticle: 35122
I didn't reply immediatly because I have a Verilog bent. Knowing what I do about Synplify, you should be able to get the Virtex CLB clock enable pins worked into your code easily. No tricks. There is one directive (attribute?) that might help for some signals - look up syn_isenable on Synplify's online help; I think that's valid but can't check quickly. Be aware that CLBram and SRL instances won't pack nicely with write enables and register resets. BlockRams also may need a little help. In Verilog the clock enable would just be one big "if" statement wrapped around everything inside my "always" blocks. Charles Ross wrote: > Im interested in making use of the clock enable pins > that exist in the Virtex CLBs. > > I have got a VHDL component, which expects a streams > of values to be entered in serial. However, the I/O > bandwidth of my board is not sufficient to supply the > stream. I would like to specify a value to be used as > the clock enable for the entire component. This way > I would be able to prepare one set of values, raise the > clock enable for just one clock cycle, then lower it > again while I prepare the next set of values. > > The VHDL component is behavioral, and computer generated. > So, I am unable to modify the code which generates it, or > I would have added a "data valid" signal to the component > This is unfortunatly not possible. It also contains > several other components, which I also cannot modify. > > I thought about using a gated clock, IE: > my_gated_clock <= CLK and my_clock_enable; > > And then using the gated clock to drive the clock of > the component, but this seems quite primitive, and > likly to cause clock scew, or other nasty problems. > I know that clock signals have dedicated resources > and it occured to me that using a gated clock would > cause the clock signal to be a regular signal, which > might cause problems. I am uneasy about messing with > the actual clock lines. > > I looked around in the synplify manuals and found > an attribute called "syn_direct_enable" which appears > to be for specifying a clock enable for a component, > but the description of the attribute is poor. I have > not been able to get it to work. > > If I am able to figure out how to easily make use of > the Clock enable I will be able to use them for other > "data valid" type signals to generate more efficient > code. > > Any suggestions? Examples? > > -- > _____ _____ > ___ | | __ | > |___| | --| -| > |_____|__|__|Article: 35123
You got it. The problem is entirely the change in the delay line with the changing environment. If the voltage, or temperature changes, you are going to be unlocked when that next rising edge comes along. We estimated that it would take about 1 ms for the micro-environment to change enough to lose lock this way...it is really hard to estimate what the worst case drift of a few hundred buffers are in the delay line chain. When you add in power supply ripple, SSO's, and all of the other normal stuff, it isn't recommended. Thanks, Austin John_H wrote: > I sincerely appreciate your insight and assistance in this newsgroup. You and Peter > Alfke are great resources to help pass along these Xilinx details to people who need > them. So please see my continuing desire to understand in a positive light :-) > > When there is no clock activity, there is no CLKFB and there is no CLKIN for the > Xilinx DLL. Since the DLL was "trained" earlier by a clock that caused the DLL to > choose a delay tap, the delay is set and fixed (for now). When the clock starts up > again, the CLKIN has an edge but CLKFB is absent. Once CLKIN propagates through the > delay line, CLKFB will be present and (if CLKIN has the same period it had before) the > phases will match. The only "window" is CLKIN relative to CLKFB. So if a clock has > been absent long enough for CLKFB to flatline, the new phase alignment is arbitrary. > > If the above sequence of events doesn't describe the operation, what is the window > referenced to? > > - John > > Austin Lesea wrote: > > > John_H, > > > > No there is not a free running clock. There is a delay line. > > > > The incoming edge stops happening. The delay line empties out. > > > > There is no CLKFB signal now. > > > > Now you start again. The CLKFB signal comes in again (some cyles later). When it > > does, it has to be in the window wrt to the CLKIN signal, or you lose lock. > > > > AustinArticle: 35124
Priced for quick turnover apparently unused Contact Tony Stein
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