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
On Sep 23, 11:50 am, Rob <BertyBoos...@googlemail.com> wrote:
> Hi Svenn,
>
> In ISE, if you right click on the "synthesize -XST" process and then
> select the "Xilinx Specific Options" category there's a "Number of
> clock buffers" option. I think that if you reduce this to zero then
> XST will not automatically add any global buffers. This might fix your
> problem.
I will try this, but I actually only want my sclk_int signals to not
allocate global clock ressources. I have a lot of other things that
need those clock ressources. I looked for "local clock" in xilinx
support, but I just hit an example for ddr ram in a different FPGA
than I use. Don't know if that is what I wanted, don't think so.
>
> I'm not sure exactly what you are trying to do, but it possible that
> your ASIC methodology doesn't fit FPGA methodology very well (i know
> nothing about ASIC design).
> If you want to generate an in phase div 2 clock then this can be
> easily achieved with the DCM modules.
I'll try to explain what I want to do:
I have something like ten SPI modules running at different speeds
related to the system clock. Some are running at div 2, some at div 4
and some at div 16. The SPI entities have a little bit different
behaviour depending on the external module they are communicating
with; some peripherals start sending valid data right away, some after
3 negative edges on sclk and some need close relation between the sync
and the edges of the sclk. I do not have enough DCM modules to cover
all my needs for the complete design.
>
> Alternately you could clock all logic with the same clock and use the
> clock enable signal to load the register every other clock cycle. If
> necessary you can also define multi-cycle paths to ease the timing
> requirements.
The problem I see with using clock enable, is that the clocking of the
shift registers inside the SPI module will run at system clock speed.
The shift register receives the bits from the spi_data line one at a
time clocked by the sclk_int clock in my current implementation. If
sclk_int is just a clock enable, then the shift register will be
advanced one bit every system clock as long as sclk_int is high. The
shift register will then be finished long before the peripheral unit
has sent all its data.
process(clk) is
if rising_edge(clk) then
if sclk_int = '1' then
-- all registers in here will be clocked on each rising edge of
clk as long as sclk_int is high
-- if sclk is 16 times slower than system clock a 16 bit shift
register on spi data will be
-- finished during the first bit of data from the peripheral.
Obviuosly a bug.
end if;
end if;
end process;
>
> You can clock registers with general routing in FPGAs, but I would say
> that you should definitely avoid this unless it is absolutely
> necessary.
I would guess that SPI is such a common entity also in FPGA that such
an entity has been implemented hundreds of times by different
designers. If FPGA technology more or less enforces the use of system
clock and clock enable at lower speed, then this problem must have
been solved. If it is a problem at all.
In ASIC, I would just buffer up the system clock at the input of the
entity and use it as I like inside the entity. The global clock net
would then see only one added fan-out load (the buffer) and I would
later in post-layout simulation make sure that my buffer is large
enough to drive my internal sclk. I accept that there is a difference
between FPGA and ASIC and I do not try to enforce my ASIC mentality
into the FPGA domain. I try to learn the dos and donts of FPGA and I
find it a bit like learning c++ after coding c for years. It is a
different way of thinking and sometimes old experience is a stumbling
stone.
Thanks for your input.
--
Svenn
Article: 135251
On Sep 23, 7:39=A0am, Svenn Are Bjerkem <svenn.bjer...@googlemail.com>
wrote:
>
> I'll try to explain what I want to do:
> I have something like ten SPI modules running at different speeds
> related to the system clock. Some are running at div 2, some at div 4
> and some at div 16. The SPI entities have a little bit different
> behaviour depending on the external module they are communicating
> with; some peripherals start sending valid data right away, some after
> 3 negative edges on sclk and some need close relation between the sync
> and the edges of the sclk. I do not have enough DCM modules to cover
> all my needs for the complete design.
>
You create a counter that counts from 0 to 1 (for the div 2 case), a
counter that counts from 0 to 3 (for the div 4 case) and one that
counts from 0 to 15 (for the div 16 case). I'm not sure from your
description if all of these are running in parallel and you need 10
different controllers or you simply need one controller that operates
in different ways at different times. Read on for how you use the
counters.
>
> > Alternately you could clock all logic with the same clock and use the
> > clock enable signal to load the register every other clock cycle. If
> > necessary you can also define multi-cycle paths to ease the timing
> > requirements.
>
> The problem I see with using clock enable, is that the clocking of the
> shift registers inside the SPI module will run at system clock speed.
> The shift register receives the bits from the spi_data line one at a
> time clocked by the sclk_int clock in my current implementation. If
> sclk_int is just a clock enable, then the shift register will be
> advanced one bit every system clock as long as sclk_int is high.
But who said you had to use sclk_int as the clock enable? The
previously mentioned counters basically tell you what phase of 'sclk'
you're currently in. For the div 16 case, when the counter =3D 7 you're
halfway through the sclk clock cycle, that particular count then
corresponds to either a rising or falling edge of sclk (whichever you
choose it to be). In fact, in addition to generating output data and
sampling input data with specific counter states you would also
generate the sclk output from this counter.
Ex (the div 16 case)
process(Clock)
begin
if rising_edge(Clock) then
if (Reset =3D '1') or (clk_divider_counter =3D 15) then
sclk <=3D '0';
elsif (clk_divider_counter =3D 7) then
sclk <=3D '1';
end if;
end if;
end process;
Upon perusing this, you can see that when the clock divider counter
reaches the halfway point and the end point you're at an 'edge' on
sclk so you would sample the SPI input data at a specific count value
and generate the SPI output data at a (possibly) different count
value. Those shift register contents then would only be shifting on a
specific count of the shift register which will only occur once for
each shift register on every full sclk cycle.
>
> I would guess that SPI is such a common entity also in FPGA that such
> an entity has been implemented hundreds of times by different
> designers. If FPGA technology more or less enforces the use of system
> clock and clock enable at lower speed, then this problem must have
> been solved. If it is a problem at all.
>
It has been solved.
> In ASIC, I would just buffer up the system clock at the input of the
> entity and use it as I like inside the entity. The global clock net
> would then see only one added fan-out load (the buffer) and I would
> later in post-layout simulation make sure that my buffer is large
> enough to drive my internal sclk. I accept that there is a difference
> between FPGA and ASIC and I do not try to enforce my ASIC mentality
> into the FPGA domain. I try to learn the dos and donts of FPGA and I
> find it a bit like learning c++ after coding c for years. It is a
> different way of thinking and sometimes old experience is a stumbling
> stone.
>
It seems here that your only stumbling block here is that in order to
generate any form of clock enable that is a certain number of system
clock cycles, you've forgotten that there must be some form of counter
used. Any specific values of the counter's current state decode to
something that will only occur once per cycle (i.e. "if (counter =3D 7)
then...". The thing used as a clock enable (i.e. counter =3D 7) does
not need to conform to any external signalling requirements (i.e.
generating a 50% duty cycle 'sclk').
Kevin Jennings
Article: 135252On Sep 23, 12:44=A0am, mkr <mahenre...@gmail.com> wrote: > I have designed a clock divider as part of my first project > (UART). If the clock divider is set to divide by 10 I have an output > clock that is ON for one pulse and OFF for ten pulses so the output > duty cycle is 10%. I can modify the HDL to make it ON for five pulses > and again OFF for the next five pulses and achieve 50% duty cycle with > the same clock rate. In either cases I would like to know the impact > (not necesarily for UART but in general to the digital systems) and > what is the significance of duty cycle and what difference does it > make make to digital systems? For inputs signals that use some edge to sample data, datasheets will specify a required duty cycle either explicitly (50% +/- 5% as an example) or indirectly by specifying a 'clock high time' and 'clock low time' (or 'high time' and 'clock period'). In any case, there will be some requirement for some amount of time that the clock signal is in a specific state. By creating a 50% duty cycle clock you're bound to meet those requirements. Many devices though do not require anything remotely close to a 50% duty cycle clock (take a look at a simple 74F374 as an example). The ones that do are generally because that input does much more than simply sample data on input pins. You must meet the requirements of the datasheet, but exceeding them doesn't mean things work any better, it might however mean that you have more margin in your design. Bottom line is that 50% duty cycle clocks don't work any better than 10% duty cycle clocks but the 50% clock might provide cover for other design issues (like maybe slow slew rates because the signal has a higher than expected capacitive load). KJArticle: 135253
On Sep 23, 11:39=A0am, Svenn Are Bjerkem <svenn.bjer...@googlemail.com> wrote: > On Sep 23, 11:50 am, Rob <BertyBoos...@googlemail.com> wrote: > > > Hi Svenn, > > > In ISE, if you right click on the "synthesize -XST" process and then > > select the "Xilinx Specific Options" category there's a "Number of > > clock buffers" option. I think that if you reduce this to zero then > > XST will not automatically add any global buffers. This might fix your > > problem. > > I will try this, but I actually only want my sclk_int signals to not > allocate global clock ressources. I have a lot of other things that > need those clock ressources. I looked for "local clock" in xilinx > support, but I just hit an example for ddr ram in a different FPGA > than I use. Don't know if that is what I wanted, don't think so. > > > > > I'm not sure exactly what you are trying to do, but it possible that > > your ASIC methodology doesn't fit FPGA methodology very well (i know > > nothing about ASIC design). > > If you want to generate an in phase div 2 clock then this can be > > easily achieved with the DCM modules. > > I'll try to explain what I want to do: > I have something like ten SPI modules running at different speeds > related to the system clock. Some are running at div 2, some at div 4 > and some at div 16. The SPI entities have a little bit different > behaviour depending on the external module they are communicating > with; some peripherals start sending valid data right away, some after > 3 negative edges on sclk and some need close relation between the sync > and the edges of the sclk. I do not have enough DCM modules to cover > all my needs for the complete design. > > > > > Alternately you could clock all logic with the same clock and use the > > clock enable signal to load the register every other clock cycle. If > > necessary you can also define multi-cycle paths to ease the timing > > requirements. > > The problem I see with using clock enable, is that the clocking of the > shift registers inside the SPI module will run at system clock speed. > The shift register receives the bits from the spi_data line one at a > time clocked by the sclk_int clock in my current implementation. If > sclk_int is just a clock enable, then the shift register will be > advanced one bit every system clock as long as sclk_int is high. The > shift register will then be finished long before the peripheral unit > has sent all its data. > > process(clk) is > =A0 if rising_edge(clk) then > =A0 =A0 if sclk_int =3D '1' then > =A0 =A0 =A0 -- all registers in here will be clocked on each rising edge = of > clk as long as sclk_int is high > =A0 =A0 =A0 -- if sclk is 16 times slower than system clock a 16 bit shif= t > register on spi data will be > =A0 =A0 =A0 -- finished during the first bit of data from the peripheral. > Obviuosly a bug. > =A0 =A0 end if; > =A0 end if; > end process; > > > > > You can clock registers with general routing in FPGAs, but I would say > > that you should definitely avoid this unless it is absolutely > > necessary. > > I would guess that SPI is such a common entity also in FPGA that such > an entity has been implemented hundreds of times by different > designers. If FPGA technology more or less enforces the use of system > clock and clock enable at lower speed, then this problem must have > been solved. If it is a problem at all. > > In ASIC, I would just buffer up the system clock at the input of the > entity and use it as I like inside the entity. The global clock net > would then see only one added fan-out load (the buffer) and I would > later in post-layout simulation make sure that my buffer is large > enough to drive my internal sclk. I accept that there is a difference > between FPGA and ASIC and I do not try to enforce my ASIC mentality > into the FPGA domain. I try to learn the dos and donts of FPGA and I > find it a bit like learning c++ after coding c for years. It is a > different way of thinking and sometimes old experience is a stumbling > stone. > > Thanks for your input. > > -- > Svenn > I will try this, but I actually only want my sclk_int signals to not > allocate global clock ressources. I have a lot of other things that > need those clock ressources. I looked for "local clock" in xilinx > support, but I just hit an example for ddr ram in a different FPGA > than I use. Don't know if that is what I wanted, don't think so. Where you actually want a clock buffer you can instantiate a BUFG component. I've implemented an SPI interface running at about 10MHz. My implementation used a system clock running at about 100MHz. The SPI signals where treated as async signals and double registered into the FPGA. It's then trivial to detect a rising edge on the SCLK line and do something in a state machine, or toggle the state of a signal at the right time. Obviously this approach won't work if your SPI frequency approaches you system clock frequency. Could you possibly increase your system clock frequency? If you are stuck having to run an SPI interface at sys_clk/2 you could implement these interfaces with global/regional clocks and implement the slower interfaces using state machines and treating the SPI signals as asynchronous. You could also consider using a different device with more global clocks -Virtex5 devices have 32 (but cost the Earth!).Article: 135254
On Sep 23, 6:39=A0am, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Tue, 23 Sep 2008 01:38:24 -0700 (PDT), Svenn Are Bjerkem > > > > <svenn.bjer...@googlemail.com> wrote: > >Hi, > > >coming from ASIC I have probably a lot to learn about FPGA clocking. > >While total control/responsibility for clock trees in an ASIC, it > >seems that the synthesiser (in my case ISE 10.1) does a lot of magic > >without me knowing about it. I have read some threads here that tells > >me to use global clock and clock enable for modules running at lower > >speeds than global clock. > > >My current scheme was: > >divby2 : process(clk) is > > =A0sclk_int <=3D not sclk_int; > >end process divby2; > > >usedivby2 : process(sclk_int) is > > =A0if rising_edge(sclk_int) then > > =A0 =A0-- do something with the divided clock > > =A0end if; > >end process usedivby2; > >After adding several of these entities in my design, ISE starts > >complaining about problems with clock routing. > > You are thinking along the right lines. This form of "usedivby2" does > generate another clock. Which is not entirely wrong, but definitely > discouraged, in an FPGA. > > A GOOD use for it could be to clock the majority of your logic off a > lower frequency clock, and (a) save power, and (b) relax the timing > constraints WITHIN that lower frequency clock domain. > > The drawbacks are twofold; > (1) since the divided clock is delayed wrt the original, you have to pay > special attention to signals originating in one clock domain and > terminating in the other. This is probably a bigger problem in FPGA than > in ASIC because routing delays tend to dominate (aside from the simple > headache of creating and verifying cross-domain timing constraints). > > (2) as you found, each clock consumes a limited resource - a clock tree > spanning typically either the whole FPGA or a single quadrant. You may > have only 4 or 8 to play with. > > For most purposes use the clock enable form: > > usedivby2_better : process(clk) is > =A0 if rising_edge(clk) then > =A0 =A0 if sclk_int =3D '1' then > =A0 =A0 =A0 =A0-- do something with the divided clock as an enable > =A0 =A0 end if; > =A0 end if; > end process usedivby2_better; > > Use it everywhere to keep the entire design synchronous to clk; > timing constraints are very simple and reliable. > You can also use "if rising_edge(clk) and clk_enable =3D '1' then" to get the clock enable. This is a less invasive modification to the original code (no extra indentation, end if, etc.), especially when you know that every register in the process must have the clock enable. AndyArticle: 135255
mkr wrote: > I am new to this area and trying to learn the baics. I understand what > duty cycle is but really want to know it's significance in digital > design. I have designed a clock divider as part of my first project > (UART). If the clock divider is set to divide by 10 I have an output > clock that is ON for one pulse and OFF for ten pulses so the output > duty cycle is 10%. I can modify the HDL to make it ON for five pulses > and again OFF for the next five pulses and achieve 50% duty cycle with > the same clock rate. In either cases I would like to know the impact > (not necesarily for UART but in general to the digital systems) and > what is the significance of duty cycle and what difference does it > make make to digital systems? For very slow clocks and systems that use only the posedge clk and where all signals are internal, there's no issue. If a clock is rather fast, the minimum acceptable clock high (or low) time for proper operation of the register could be violated with a very short (or long) duty cycle. If the negedge and posedge clk are both used, the propagation delay from one edge domain to the other is significantly skewed from the opposite domain crossing. If the clock is provided to external circuits, sometimes those circuits have requirements that aren't obvious to the casual designer. If the external circuit you interface to has no duty-cycle requirements, you're fine, but sometimes they have duty cycle needs for reasons similar to those above. Analog requirements for external circuits may also dictate duty cycle limits.Article: 135256
> Seehttp://www.altera.com/literature/wp/wp-01034-Utilizing-Leveling-Techn... > for more detail. OK, that makes sense. Do the Arria parts have this capability as well? Which parts can support a 533MHz DDR3 clock right now? -MartinArticle: 135257
On Sep 23, 8:37=A0am, Rob <BertyBoos...@googlemail.com> wrote: > > The SPI > signals where treated as async signals and double registered into the > FPGA. It's then trivial to detect a rising edge on the SCLK line and > do something in a state machine, or toggle the state of a signal at > the right time. This would be true for a SPI slave device, but it appears that Svenn is implementing the SPI controller in which case none of the async signals, double registering, detecting a rising edge on SCLK is appropriate. From the SPI controller's perspective it is a completly synchronous subsystem since it is the one generating SCLK and it should be doing so synchronously to it's system clock. Kevin JenningsArticle: 135258
On Sep 23, 2:52 pm, Andy <jonesa...@comcast.net> wrote:
>
> You can also use "if rising_edge(clk) and clk_enable = '1' then" to
I was told explicitly by a textbook that this isn't synthesisable so I
never tried it out.
I tried out turning off all available clock buffers as suggested by
Rob. That led to success in synthesizing, but also a couple of
interesting warnings from the synthesizer. I searched on xilinx
support and found that I could set an attribute called "buffer_type"
architecture rtl of spi_ad7468 is
signal sclk_int : std_logic; -- SPI clock
attribute BUFFER_TYPE : string;
attribute BUFFER_TYPE of sclk_int : signal is "none"; -- use
local net
begin
...
end rtl
Inserting this attribute into the different SPI blocks and turning on
all clock buffers in ISE again gave a very pleasing result: All
sclk_int signals were now flagged as "Local", and all the "real and
important" clock nets were assigned to proper BUFGs. Since this
attribute is assigned explicitly in the places where I really need
them I hope to have solved my problem. Maybe I will expect other
problems due to this solution later, we'll see.
Obviously, I should be very very careful with the use of this
attribute due to clock skew. Main target now was to get some code
running without rewriting too much, but next time I will consider
using more proper clocking strategies. Thanks a lot for all input.
--
Svenn
Article: 135259Hi Can I just connect the mode select pins (M0-M2) to power/gnd depending on my required programming mode or do I need to connect them to resistors? If I select a master serial mode will it prevent me from using JTAG. Cheers JonArticle: 135260
Svenn Are Bjerkem wrote: > Hi, > > coming from ASIC I have probably a lot to learn about FPGA clocking. > While total control/responsibility for clock trees in an ASIC, it > seems that the synthesiser (in my case ISE 10.1) does a lot of magic > without me knowing about it. I have read some threads here that tells > me to use global clock and clock enable for modules running at lower > speeds than global clock. > > My current scheme was: > divby2 : process(clk) is > sclk_int <= not sclk_int; > end process divby2; > > usedivby2 : process(sclk_int) is > if rising_edge(sclk_int) then > -- do something with the divided clock > end if; > end process usedivby2; > > After adding several of these entities in my design, ISE starts > complaining about problems with clock routing. When looking into the > synthesiser report, I see that all those sclk_int signals are assigned > to BUFGs and I am presuming that my derived clocks are using up all > the clocking ressources in the spartan3A DSP that I am using. In ASIC > this was never an issue as clocks are just signals (though I have to > care about my clock tree). > > I guess the fact that sclk_int is in the sensivity list of the process > and that rising_edge(sclk_int) identifies sclk_int as a clock to the > synthesiser. > > I have a hard time to find a section in the xilinx documentation > telling me what is actually happening in this case, but I presume I > will have to rewrite my code to use sclk_int as a clock enable signal. > I did actually to this in one module, but that generated flip-flops > clocked with global clock on the signals to store the value. I thought > that looked ugly and unnescessary, but maybe it isn't in FPGA design. > > I presume it is not possible to tell the synthesiser that "sclk_int is > just another signal, but please use it as a clock for these LUTs" in > order to save me some recoding. > > -- > Svenn The point of the clock chains in an FPGA is to provide a low skew clock signal over the chip. The non clock routing is much slower and will cause great grief if used for clocks, even at low speeds. The design philosophy was to clock all the flip flops all the time and use the clock enable to decide if you want them to change. If the clock enable is low, it just reclocks the output value into the flip flop. Gated clocks are evil. Mltiple clocks which come from the same master clock should be avoided and replaced with clock enables. Your life will be much easier that way.Article: 135261
David R Brooks wrote: > thutt wrote: > >>Kevin Neilson <kevin_neilson@removethiscomcast.net> writes: >> >> >>>thutt wrote: >>> >>>>Hello everyone, >>>>I'm tired of using the Xilinx ISE to look at RTL schematics, mainly >>>>because it's so slow and cumbersome to use. What I'd like to do is >>>>output a netlist and use another script to process that netlist into >>>>input suitable for VCG (http://rw4.cs.uni-sb.de/~sander/html/gsvcg1.html). >>>>I have figured out how to get the Xilinx tools to output a netlist, >>>>but it appears they output a 'technology' version and not an 'RTL' >>>>version of the netlist. >>>>Is there any way to get the tools to output a netlist that is in the >>>>more useful (to me) 'RTL' format? >>>>My desire is to be able to write VHDL code, build it with my build >>>>process and check the RTL without ever having to enter Xilinx's IDE. >>>>I'd also like to be able to easily extract schematics for inclusion >>>>into the chronicle of my personal project at >>>>http://www.harp-project.com/, but the Xilnix tools make this >>>>incredibly difficult. >>>>Thanks for any info, >>>>thutt >>>> >>> >>>I think the RTL schematic is in a proprietary format. I don't know if >>>it's possible to view it in another tool. If you want a better viewer >>>for the technology schematic, you can import the NGC into PlanAhead, >>>which now comes with ISE. If you want a better RTL viewer, you >>>probably have to resynthesize with a different synthesizer and view >>>the schematic in that tool. -Kevin >> >>I don't understand how the RTL can be in a proprietary format, if I'm >>reading the technology schematic correctly. As far as I can tell, >>each LUT in the technology schematic represents some level of >>'complex' logic which can be viewed in RTL form by double clicking on >>the LUT in the technology schematic viewer. >> >>Each LUT also has an associated initialization value, a 16-bit >>hexadecimal number; I assume that the initialization value is the key >>which turns the lock and causes the LUT to implement a certain >>functionality. >> >>If that's the case, has anyone spent the time to figure out the >>mappings of initialization codes to LUT implementations? Or, does >>Xilinx publish this information? (I seem to recall a post in either >>this newsgroup or comp.lang.vhdl which described how this was derived, >>but I don't recall if it went into any specificity with regards to >>Xilinx initialization values). >> >>If there were a lookup table of initialization values to the standard >>'and / or / xor'-type logic that each represents, then it would be >>quite possible to write a script to make an external RTL viewer based >>on the technology netlist output by the Xilinx tools. >> >>Anyone game for a little sleuthing to determine all the LUT init >>codes? >> > > > It's a bit harder than that. Assume a LUT has 4 inputs (it varies > with different FPGA families). The synthesiser (eg XST) will look for a > piece of combinatorial logic with 4 inputs & 1 output. It then simulates > that logic, evaluating its output for all 16 possible input > combinations. The initialisation string is simply the map of those 16 > outputs, written out in hex. > So there really isn't an underlying logic representation: the designer > might have specified any Boolean function whatever (adder, parity tree, > etc): the synthesiser doesn't care. > The actual LUT is a 16x1 memory so the sixteen bits are the memory contents. As stated in the answer above, the original logic has been compressed and is not available.Article: 135262
> The low pass filter will not give you a sine wave. =A0It will > approximate one, but with 20 MHz components on a 10 MHz signal, you > will not be able to fully filter it out. Is that because the FPGA will not generate a perfect square wave? I purchased a DAC but it seemed like a waste to send 8 bits at a time when there are really only two values. Anyway, thanks for the info. BrianArticle: 135263
On Sep 23, 9:54=A0am, Svenn Are Bjerkem <svenn.bjer...@googlemail.com> wrote: > On Sep 23, 2:52 pm, Andy <jonesa...@comcast.net> wrote: > > > > > You can also use "if rising_edge(clk) and clk_enable =3D '1' then" to > > I was told explicitly by a textbook that this isn't synthesisable so I > never tried it out. > > I tried out turning off all available clock buffers as suggested by > Rob. That led to success in synthesizing, but also a couple of > interesting warnings from the synthesizer. I searched on xilinx > support and found that I could set an attribute called "buffer_type" > > architecture rtl of spi_ad7468 is > =A0 =A0 signal sclk_int =A0 =A0 =A0 : std_logic; -- SPI clock > > =A0 =A0 attribute BUFFER_TYPE : string; > =A0 =A0 attribute BUFFER_TYPE of sclk_int : signal is "none"; =A0-- use > local net > begin > ... > end rtl > > Since this > attribute is assigned explicitly in the places where I really need > them I hope to have solved my problem. Maybe I will expect other > problems due to this solution later, we'll see. > I would expect that there would be timing issues on the clock domain transfers...specifically, setup/hold time on signals originating in the system clock domain and being used in the sclk domain when the part is running 'fast'. > Obviously, I should be very very careful with the use of this > attribute due to clock skew. Main target now was to get some code > running without rewriting too much, but next time I will consider > using more proper clocking strategies. Thanks a lot for all input. > Clock skew in FPGAs are not controllable by the designer which is the fundamental reason why FPGA designs tend to not use gated or logic/ flop divider derived clocks but in ASIC land these methods can be used because clock skew is controllable. Unless both fast/slow static timing analysis has passed, any time spent now getting this 'running' will likely fall victim to intermittent failures due to timing issues caused by the improper use of multiple clock domains and the inability to control clock skew...welcome to FPGA land. KJArticle: 135264
thutt wrote:
> Kevin Neilson <kevin_neilson@removethiscomcast.net> writes:
>
>> thutt wrote:
..snip..
>
> Each LUT also has an associated initialization value, a 16-bit
> hexadecimal number; I assume that the initialization value is the key
> which turns the lock and causes the LUT to implement a certain
> functionality.
>
> If that's the case, has anyone spent the time to figure out the
> mappings of initialization codes to LUT implementations? Or, does
> Xilinx publish this information? (I seem to recall a post in either
> this newsgroup or comp.lang.vhdl which described how this was derived,
> but I don't recall if it went into any specificity with regards to
> Xilinx initialization values).
>
> If there were a lookup table of initialization values to the standard
> 'and / or / xor'-type logic that each represents, then it would be
> quite possible to write a script to make an external RTL viewer based
> on the technology netlist output by the Xilinx tools.
>
> Anyone game for a little sleuthing to determine all the LUT init
> codes?
There is nothing secret at all about the LUT INIT values. A LUT4 has a
INIT[3:0] string representing 16 values (2^4) where inputs I0=0, I1=1,
I2=2, and I3=3 or otherwise written as INIT[{I3,I2,I1,I0}]. It is
trivial to convert the truth table to a boolean equation using a
Karnaugh map http://en.wikipedia.org/wiki/Karnaugh_map
A LUT5 and LUT6 operate in the same way, just with 5 and 6 bit strings.
Ed McGettigan
--
Xilinx Inc.
Article: 135265On Sep 23, 6:25 pm, doug <x...@xx.com> wrote: > > The most dangerous thing to do with nonglobal clocks is shift registers. > Any skew will make them malfunction and each placement will be > different. As long as you do not care about the data in your SPI > you will be ok. If you do care, it is a good idea to do the design > correctly. Well, I do care about the data in the shift registers so it looks like I will eventually have to recode the spi entities properly. Thanks for your warning. -- SvennArticle: 135266
Svenn Are Bjerkem wrote: > On Sep 23, 2:52 pm, Andy <jonesa...@comcast.net> wrote: > >>You can also use "if rising_edge(clk) and clk_enable = '1' then" to > > > I was told explicitly by a textbook that this isn't synthesisable so I > never tried it out. > > I tried out turning off all available clock buffers as suggested by > Rob. That led to success in synthesizing, but also a couple of > interesting warnings from the synthesizer. I searched on xilinx > support and found that I could set an attribute called "buffer_type" > > architecture rtl of spi_ad7468 is > signal sclk_int : std_logic; -- SPI clock > > attribute BUFFER_TYPE : string; > attribute BUFFER_TYPE of sclk_int : signal is "none"; -- use > local net > begin > ... > end rtl > > Inserting this attribute into the different SPI blocks and turning on > all clock buffers in ISE again gave a very pleasing result: All > sclk_int signals were now flagged as "Local", and all the "real and > important" clock nets were assigned to proper BUFGs. Since this > attribute is assigned explicitly in the places where I really need > them I hope to have solved my problem. Maybe I will expect other > problems due to this solution later, we'll see. > > Obviously, I should be very very careful with the use of this > attribute due to clock skew. Main target now was to get some code > running without rewriting too much, but next time I will consider > using more proper clocking strategies. Thanks a lot for all input. > > -- > Svenn The most dangerous thing to do with nonglobal clocks is shift registers. Any skew will make them malfunction and each placement will be different. As long as you do not care about the data in your SPI you will be ok. If you do care, it is a good idea to do the design correctly.Article: 135267
Hi Svenn, To recap this thread: 1. Every signal used as a clock will be handled as such by your FPGA tool chain. One typically distinguishes 'gated clocks' from 'generated clocks' (or divided clocks). Gated clocks turn the master clock ON or OFF, while a generated clock is a arbitrary clock constructed with any mix of random logic and analog IPs such as PLLs/DCMs. 2. FPGAs have built-in clock trees, with very low skew. Depending on your device, there are between 2 to 32 global clock trees, spanning the entire area of the chip. Some devices also offer local clocks, wich span a subset of the chip area. Access to these clock trees is typically materialized through the insertion of a clock buffer. Most synthesis tools insert global clock buffers automatically. 3. While each clock tree has a very low skew, it typically exhibits a significant insertion delay (latency) - several nanoseconds are common. The insertion delay is not constant, and heavily depends from the placement (clock IO pad, clock buffer, sequential elements). Consequently, the offset between two distinct clocks is a severe hurdle in FPGAs: it can be large; it varies from run to run; it's extremely hard to control. For that reason, cross-clock paths need to be handle very carefully in FPGAs. One approach is to treat the clocks as asynchronous, using double-FF for single-bit interface, and FIFOs for multi-but interface. 4. The power savings from gated/generated clock are marginal in FPGAs. These structures are common in ASICs, but undesired, and in fact dangerous in FPGAs. Aside from manually recoding your design (painful), I would recommend using the Synopsys (formerly Synplicity) Synplify Pro synthesis tool. It can automatically convert gated clocks and generated clocks during synthesis. Synplify implements the same methodology you would do manually: it uses clock enables. As you noted previously, the generated-clock conversion is the most difficult as the clock-enable 'high' period must exactly coincide with an edge of the original generated-clock. 5. Once you have converted your generated clock, you will probably need to add multi-cycle paths constraints to avoid false critical paths. Here, any tool that has a powerful Tcl Find command comes handy to create a collection of FFs that share the same clock-enable signal. Good luck with your design, - gaelArticle: 135268
thutt wrote: > Kevin Neilson <kevin_neilson@removethiscomcast.net> writes: > >> thutt wrote: >>> Hello everyone, >>> I'm tired of using the Xilinx ISE to look at RTL schematics, mainly >>> because it's so slow and cumbersome to use. What I'd like to do is >>> output a netlist and use another script to process that netlist into >>> input suitable for VCG (http://rw4.cs.uni-sb.de/~sander/html/gsvcg1.html). >>> I have figured out how to get the Xilinx tools to output a netlist, >>> but it appears they output a 'technology' version and not an 'RTL' >>> version of the netlist. >>> Is there any way to get the tools to output a netlist that is in the >>> more useful (to me) 'RTL' format? >>> My desire is to be able to write VHDL code, build it with my build >>> process and check the RTL without ever having to enter Xilinx's IDE. >>> I'd also like to be able to easily extract schematics for inclusion >>> into the chronicle of my personal project at >>> http://www.harp-project.com/, but the Xilnix tools make this >>> incredibly difficult. >>> Thanks for any info, >>> thutt >>> >> I think the RTL schematic is in a proprietary format. I don't know if >> it's possible to view it in another tool. If you want a better viewer >> for the technology schematic, you can import the NGC into PlanAhead, >> which now comes with ISE. If you want a better RTL viewer, you >> probably have to resynthesize with a different synthesizer and view >> the schematic in that tool. -Kevin > > I don't understand how the RTL can be in a proprietary format, if I'm > reading the technology schematic correctly. As far as I can tell, > each LUT in the technology schematic represents some level of > 'complex' logic which can be viewed in RTL form by double clicking on > the LUT in the technology schematic viewer. > > Each LUT also has an associated initialization value, a 16-bit > hexadecimal number; I assume that the initialization value is the key > which turns the lock and causes the LUT to implement a certain > functionality. > > If that's the case, has anyone spent the time to figure out the > mappings of initialization codes to LUT implementations? Or, does > Xilinx publish this information? (I seem to recall a post in either > this newsgroup or comp.lang.vhdl which described how this was derived, > but I don't recall if it went into any specificity with regards to > Xilinx initialization values). > > If there were a lookup table of initialization values to the standard > 'and / or / xor'-type logic that each represents, then it would be > quite possible to write a script to make an external RTL viewer based > on the technology netlist output by the Xilinx tools. > > Anyone game for a little sleuthing to determine all the LUT init > codes? > > thutt The problem with turning a technology schematic into an RTL schematic is akin to turning object code into C. Sure, you can determine that a LUT with a INIT code of FFFE is an inverter. But it's hard determine that a collection of 80 LUTs is an adder, which you want to represent on an RTL schematic with a "+" sign, not as a bunch of XORs. -KevinArticle: 135269
Brian Drummond wrote: > On 20 Sep 2008 09:48:58 -0700, thutt <thutt151@comcast.net> wrote: > >> Hello everyone, >> >> I'm tired of using the Xilinx ISE to look at RTL schematics, mainly >> because it's so slow and cumbersome to use. What I'd like to do is >> output a netlist and use another script to process that netlist into >> input suitable for VCG (http://rw4.cs.uni-sb.de/~sander/html/gsvcg1.html). >> >> I have figured out how to get the Xilinx tools to output a netlist, >> but it appears they output a 'technology' version and not an 'RTL' >> version of the netlist. > >> Is there any way to get the tools to output a netlist that is in the >> more useful (to me) 'RTL' format? > > Have you looked at the post-synthesis simulation model (in VHDL)? > > - Brian The post-synthesis simulation model, if viewed in a different tool, would be about identical to a technology schematic, because all large structures have been resolved into primitives. -KevinArticle: 135270
It's not clear from your post whether you are talking about the same PHY used differently or different PHYs. PHY output drivers can be either voltage or current mode. Current mode drivers require pullup to a voltage source. Some PHYs have different dirvers in different modes of operation (e.g. 10BaseT vs. 100 or 1000BaseT). Also, there are a few different types of magnetics used, which might require different termination schemes. Try to find appnotes relevant to the PHY you are using. /Mikhail "Roger" <rogerwilson@hotmail.com> wrote in message news:xP6dnerrZZ6bakrVnZ2dnUVZ8sDinZ2d@posted.plusnet... > The paired MDI signals from the PHY to the magnetics in a GbE application > are each terminated by a 50R resistor and then together to a 10nF > capacitor > to GND. However some applications connect the 2 resistors to Vcc (2.5V) as > well. Can anyone explain why some configurations are like this and others > aren't? Is it something specific to the magnetics? > > TIA, > > Rog.Article: 135271
On Sep 23, 7:03 am, "maxascent" <maxasc...@yahoo.co.uk> wrote: > Hi > > Can I just connect the mode select pins (M0-M2) to power/gnd depending on > my required programming mode or do I need to connect them to resistors? If > I select a master serial mode will it prevent me from using JTAG. > > Cheers > > Jon Where is Peter now that we really need him? ;) IIRC, these pins have internal pullups, so all you need to do is ground the '0' pins. If pulling up, I would use a current limiting resistor. There may be a situation where the board Vcc doesn't match the internal Vcc of the configuration section. What does the data sheet recommend? And you can still enter JTAG mode with the mode pins set for serial programming. At least on some chips; which chip did you say you were using?Article: 135272
Hi > IIRC, these pins have internal pullups, so all you need to do is > ground the '0' pins. Yes, you could ground them. I use a board where this pin's are directly grounded. cheers benArticle: 135273
Some xilinx fpgas, with mode pins set to a non-jtag mode, cannot enter jtag configuration mode (via jtag command) until/unless they are successful in configuring via the mode pin designated method. In other words, if you tie the mode pins to designate configuration from a serial prom, and you don't have a valid configuration in your prom, you cannot use jtag to command the fpga to configure via jtag. AndyArticle: 135274
KJ wrote: (snip) > In any case, there > will be some requirement for some amount of time that the clock signal > is in a specific state. By creating a 50% duty cycle clock you're > bound to meet those requirements. The Intel 8086 and 8088 use a 33% duty cycle clock for maximum clock speed. Something strange in that design. > Many devices though do not require > anything remotely close to a 50% duty cycle clock (take a look at a > simple 74F374 as an example). The ones that do are generally because > that input does much more than simply sample data on input pins. You > must meet the requirements of the datasheet, but exceeding them > doesn't mean things work any better, it might however mean that you > have more margin in your design. For UARTs, there is the need to sample the data near the middle of the bit time, usually done by dividing by 16 inside the UART. All that is needed is to meet the timing for the internal clock divider. I believe, though, that it is usual for UART clock generators to generate approximately symmetric output, especially when using an even divisor. Then again, there is a divider by Peter Alfke that divides by 2.5 generating a symmetric output given a symmetric input. > Bottom line is that 50% duty cycle clocks don't work any better than > 10% duty cycle clocks but the 50% clock might provide cover for other > design issues (like maybe slow slew rates because the signal has a > higher than expected capacitive load). Clocks for microprocessors often have strict requirements. Otherwise, I pretty much agree. -- glen
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