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
>That is in the nature of DDS. >Max jitter = one clock period. >If that is acceptable, go for it. Somehow, it seems as though I should be able to get close to a half clock period. Closer "just" takes more bits of state. What am I missing? -- These are my opinions, not necessarily my employeers. I hate spam.Article: 35401
I'm with Ray on this. First on the tight design thing. Back in 1990-1991 I spent ages reverse engineering where the bits in a XC2064 bitstream were that held the LUT contents. It turned out that there were all kinds of funky modes for the LUT that affected which bits went where, sometimes bits got inverted, and so on; it took months. Eventually I managed to get this working and was able to make awesomely fast constant bus comparators where the constant was settable by software at configuration time by dynamic bitsream modification. I could also set per-configuration modes for my logic without having the overhead of addressable storage to control the modes. It even interrogated the Xilinx toolflow output files to map CLB names to placed CLB locations. I was real pleased with myself. Then I realized that I was stuck on 2000 series stuff unless I wanted to reproduce all that hard work on 3000 and then 4000, in fact over the medium term all of that effort ended up holding back the product, (although boy, it was cool :) ) So it was we were using 2064s until they were end-of-lifed, while the 'less cool' competition was on 4000s kicking my butt. After I realized what I had *really* done to myself, I swore off of extreme performance optimization at the cost of generality. Second, although it is really the same point in disguise, on the schematic vs text thing, Ray is right that the VHDL should be able to express anything you can express using schematics. This is pretty clear from the fact that both the VHDL and the schematic are turned into the same form of netlist as their first step in the toolflow. I was using a very early version of Orcad, at some huge cost, on my super duper 8086 640x480 monochrome machine, so I have some experience of schematic entry (and in fact I continue to use Protel for designing PCBs). Just think back to the last time you had to reorder a bus that you had unwisely drawn all the lines in for and you'll have to admit that text, with all the amenities available in a good editor beats out all the area management dross in 2D schemtics. And if you say to yourself, 'ha! that ain't fair, as I use bus member labelling for connectivity without the lines', then consider that you are in fact using plain text to replace schematic elements. Now having said that, I also believe that some people have a greater facility with images than text and others are vice versa. So long as the content of the schematic uses retartgetable primitives then it is probably defensible to go on using schematics. But there are real advantages to pure text, all the advantages that software people know and love. I know I would rather have a bunch of proven VHDL components than a stack of proven schematics. |I have been using VHDL for about 2 years now, and this is for some very high speed |designs (eg. our FFT module, which is the fastest single thread FFT available for |FPGAs is done in VHDL). VHDL does let you structurally instantiate primitives, so |that you can do anything you can do with schematics, plus it has the advantage of |a generate statement, so one design can cover many uses. For example, our adder |macro creates a fully RLOC'd adder that is automatically sized to the the width of |the bus connected to its output. When we did schematics, this required a separate |schematic for each bit width (we had ways of doing that quickly too, but the |generate is even better). We were a relatively late adopter of VHDL because we |didn't start using it heavily until we could put placement in the hierarchical |source (the tools did not allow it until roughly 2nd qtr 1999). | |One thing that I won't do is use more than one entry tool on a particular |project. Most customers wouldn't tolerate having to buy seats of two different |tools in order to maintain a design that could have been done with just one tool. | | |Duane Hague wrote: | |> To be a bit less subtle, my point was that IMO schematic entry should |> remain part of the designers tool kit. HDL synthesizers use an "N-bit" |> modular translation approach because it would be too complex to include |> optimization for all cases of "input width" versus "architecture element |> width". I would suggest that the designer needs to be aware of the |> advantages and disadvantages of each entry method and to select the |> method most appropriate to each portion of the design. Over many years |> of experience, I have lost trust in anyone who proposes "the magic |> answer where one size fits all" (i.e. certain HDL True Believers). |> |> With regards to "reuse": If your EDA tools do not support both HDL and |> schematic entry as well as mixed entry modes; I would argue that you |> need to consider the use of other EDA tools! I would not be happy with |> any EDA tools that did not allow more than one mode of design entry. |> |> Respectfully, |> Duane Hague -- Posted using Nographer - News in your Browser http://www.nographer.com - free, open source, and smartArticle: 35402
The error which manifests itself as jitter is due to truncation of lower
bits, which is done to get a square wave out. The error is bounded by
+1,-0, which is why I said a maximum of one clock period.
Hal Murray wrote:
> >That is in the nature of DDS.
> >Max jitter = one clock period.
> >If that is acceptable, go for it.
>
> Somehow, it seems as though I should be able to get close to
> a half clock period. Closer "just" takes more bits of state.
>
> What am I missing?
>
> --
> These are my opinions, not necessarily my employeers. I hate spam.
--
--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: 35403Phil Hays <spampostmaster@home.com> wrote: > I suggest trying the new XPower utility. It seems to produce much better > estimates, at least from the starting point of a routed NCD and a simulation. It's a good utility, but a bit unwieldy. I fed in my XC2V6000 design (37% utilised so far), and a VCD file of about 100us of simulation (which was nearly a 500Mb file). XPower took almost two hours to load in the VCD and process it. I'd be a bit more confident if it wasn't (at least partly) written in Java. Anyway, I don't have any idea if the figure I got is any good, but it seems plausible. regards, Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 35404
hamish@cloud.net.au wrote: > Phil Hays <spampostmaster@home.com> wrote: > > I suggest trying the new XPower utility. It seems to produce much better > > estimates, at least from the starting point of a routed NCD and a simulation. > > It's a good utility, but a bit unwieldy. I fed in my XC2V6000 design > (37% utilised so far), and a VCD file of about 100us of simulation > (which was nearly a 500Mb file). XPower took almost two hours > to load in the VCD and process it. > > I'd be a bit more confident if it wasn't (at least partly) written in Java. > > Anyway, I don't have any idea if the figure I got is any good, > but it seems plausible. > > regards, > Hamish > -- > Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au> The use of VCD is what's put me off XPower so far. It strikes me that any decent power estimate is going to need a lot longer run than 100usec although that will be very much design dependent. If so then there are really only 3 options: o Do short runs excercising different functional areas and ``glue'' them together in some fashion to get a final estimate. Should keep the VCD sizes down at the expense of accuracy. o Generate some humongous VCD and post-process it before feeding it into XPower in a more useful format. o Change format from VCD to ???. <hobby-horse on> IMO VCD is either the most brilliantly insane thing ever invented or the most insanely brilliant; portability taken to a logical but lunatic extreme. I can remember how easily early versions of GTKWave handled the ~1GB VCD files I was being presented with i.e. not at all. <hobby-horse off>Article: 35405
Peter Alfke <peter.alfke@xilinx.com> writes: > Before anybody wastes time looking for the part number: > There never was an XC3064XL. But there is/was an XC3064L, a 3.3-V version of the > XC3064A. Maybe he was referring to the XCR3064XL? Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 35406
I have seen previous discussions involving phase shifting limits of the DCMs. Apparently you cannot go beyond + or - 255. But is 255 the number that should be used, or should it be smaller if the clock speed excedes 90 Mhz? I am trying to design an application at 350 MHz. The clock period at that speed is 2.857 ns. The minimum granularity of the phase shifter is between 40 and 50 ps. If this number is 50 ps, you could only do 57 shifts before completing a full 360 degree phase shift. Does this mean that the DCM will hang up after + or - 57 phase shifts? Or can it do 255 phase shifts, leading to a full 1600 degree phase shift in either direction? Eric MullaleyArticle: 35407
Eric, The phase shift delay line is physically limited to <10 ns. This means than at frequencies higher than ~100 MHz, you have full range control. At frequencies less than that, you will have less range, and a PS OVERFLOW will occur when you reach the beginning, or end of the line. The 10 ns number is specified with some margin (obviously) so at frequencies below 100 MHz, you may find complete range -- but don't count on every device having that behavior. Austin Eric Mullaley wrote: > I have seen previous discussions involving phase shifting limits of the DCMs. Apparently you cannot go beyond + or - 255. But is 255 the number that should be used, or should it be smaller if the clock speed excedes 90 Mhz? I am trying to design an application at 350 MHz. > > The clock period at that speed is 2.857 ns. The minimum granularity of the phase shifter is between 40 and 50 ps. If this number is 50 ps, you could only do 57 shifts before completing a full 360 degree phase shift. Does this mean that the DCM will hang up after + or - 57 phase shifts? Or can it do 255 phase shifts, leading to a full 1600 degree phase shift in either direction? > > Eric MullaleyArticle: 35408
Austin helped fill in the blanks for me... My understanding is that the DCM knows how many taps it takes to make up a period. The phase value you give it is the approximate fraction of that period. At your high clock rate, each increment or decrement of the phase won't necessarily change which tap is used. If it takes 5 increments to advance one tap, the DCM won't change the tap 4 out of 5 times. It's all scaled to one period, whether faster than 50pS*255 or slower. - John Eric Mullaley wrote: > I have seen previous discussions involving phase shifting limits of the DCMs. Apparently you cannot go beyond + or - 255. But is 255 the number that should be used, or should it be smaller if the clock speed excedes 90 Mhz? I am trying to design an application at 350 MHz. > > The clock period at that speed is 2.857 ns. The minimum granularity of the phase shifter is between 40 and 50 ps. If this number is 50 ps, you could only do 57 shifts before completing a full 360 degree phase shift. Does this mean that the DCM will hang up after + or - 57 phase shifts? Or can it do 255 phase shifts, leading to a full 1600 degree phase shift in either direction? > > Eric MullaleyArticle: 35409
Hi all. I'm running Xilinx Foundation Base Express (the one with VHDL added on). I've used this for several years and by remembering to pay for support, I've avoided getting drawn into the time-based licence thing. I received a letter recently from Xilinx, telling me that Foundation 4.1i is about to ship. All well and good. The letter goes to some length to extol the virtues of Xilinx' new ISE package, and I'm curious as to the pros and cons of moving over to this. Things that particularly concern me are: 1) What are the licence implications? I understand that Foundation is to be canned in due course. When it becomes ISE *only* will I suddenly be expected to buy a time-based licence? 2) What kind of support does ISE give to schematic entry? I foresee an ongoing need for this (partly driven from outside) for some time to come. This may include updates to Foundation projects. Any opinions would be welcome. Richard ------------Richard Dungan------------- Radix Electronic Designs, Orpington, UK richardATradixDASHdesignDOTcoDOTuk ---------------------------------------Article: 35410
It seems that the schematics are not compatible!!! And as the my local application engineer from AVNET says : there is no conversion program available, and there will never be a conversion program available. The thing is, Xilinx wants everyone to use VHDL and/or Verilog. Here is the good point, the XST synthesiser has no 'node locked' and or 'time' restrictions. So I think (and I hope) once installed, you never have to look again for new license files, ... as for example for the synopsys stuff. The bad thing is that I've used synopsys until now and while converting a project from foundation to ISE, I saw that the syntax to include constraints(like the contents of a RAM block) in HDL (verilog in my case) is different with the XST compiler. So you are fucked anyway, either schematic or HDL is not fully compatible. On the other hand, you cannot wait to start using the latest software for new things, otherwise the gap is getting bigger and bigger. Xilinx wants to sell mare and more bigger components, so the need bigger and bigger software. I think Xilinx (and also Altera) wants to go faster to new technologies than most of their customers, but everyone is forced to follow them. This is the bat thing about only two really big companys on the top of the programmable logic mountain. See you, Stefaan "Richard Dungan" <postmaster@[127.0.0.1]> schreef in bericht news:fdgmrt4apvaejfmq3ksgmhracbu5fhj9t4@4ax.com... > Hi all. > > I'm running Xilinx Foundation Base Express (the one with VHDL added on). > I've used this for several years and by remembering to pay for support, > I've avoided getting drawn into the time-based licence thing. > > I received a letter recently from Xilinx, telling me that Foundation > 4.1i is about to ship. All well and good. > > The letter goes to some length to extol the virtues of Xilinx' new ISE > package, and I'm curious as to the pros and cons of moving over to this. > > Things that particularly concern me are: > > 1) What are the licence implications? I understand that Foundation is to > be canned in due course. When it becomes ISE *only* will I suddenly > be expected to buy a time-based licence? > > 2) What kind of support does ISE give to schematic entry? I foresee an > ongoing need for this (partly driven from outside) for some time to > come. This may include updates to Foundation projects. > > Any opinions would be welcome. > > Richard > > ------------Richard Dungan------------- > Radix Electronic Designs, Orpington, UK > richardATradixDASHdesignDOTcoDOTuk > ---------------------------------------Article: 35411
hi, I think it depends so much of the design itself, that you cannot give a general rule. Sometimes, a nice looking top level done in schematic entry is better than just some text files. Specially if you are working with more people on a project, everyone has a nice overview of the global design. Sometimes you need the other way. Especially when you cannot enter constraints in the HDL code (cfr Ray Andraka). I did a processor 2 years ago and the alu was done in schematic, converted to EDIF and then placed and routed toghether with the other parts. There was now way to tell the synthsise tool to make a fast enough design for me or the pass the RLOC constraints to the par tool. Also a thing to consider : what is the important thing on what part of the design : is it the best timing and placement theoretically possible, or the fastest development or a mixture of both? I learned to make a working system in a reasonable time and with the acceptance of the fact that it can be done better, and faster, and nicer, and... but you have to make decisions on what is important. "Duane Hague" <dhague@neo.rr.com> schreef in bericht news:MPG.1623f404e41478c3989681@news-server.neo.rr.com... > In article <3BB9E8C7.4CA8327D@flukenetworks.com>, > mike.treseler@flukenetworks.com says... > > Duane Hague wrote: > > > > > By chance, I happened to have just tried designing a 32-bit barrel > > > shifter (0-31 shift, 5-bit shift index) in MaxPlus with schematic entry > > . . . > > > > > Conclusion: Could this be a nice example of why a designer should have > > > more than "one arrow in his quiver"? > > > > Certainly you can't beat packing your own primitives > > for speed and gate count. > > > > But consider that a barrel shifter might be less > > than 1% of a large design. > > > > And you might want to reuse the design in 2 years > > on newer devices. > > > > -- Mike Treseler > > > To be a bit less subtle, my point was that IMO schematic entry should > remain part of the designers tool kit. HDL synthesizers use an "N-bit" > modular translation approach because it would be too complex to include > optimization for all cases of "input width" versus "architecture element > width". I would suggest that the designer needs to be aware of the > advantages and disadvantages of each entry method and to select the > method most appropriate to each portion of the design. Over many years > of experience, I have lost trust in anyone who proposes "the magic > answer where one size fits all" (i.e. certain HDL True Believers). > > With regards to "reuse": If your EDA tools do not support both HDL and > schematic entry as well as mixed entry modes; I would argue that you > need to consider the use of other EDA tools! I would not be happy with > any EDA tools that did not allow more than one mode of design entry. > > Respectfully, > Duane HagueArticle: 35412
I am trying to use a BUFGMUX in Xilinx webpack 4.1 and Modelsim xe 5.5b
(starter) and I get the following message.
# Model Technology ModelSim XE vcom 5.5b Compiler 2001.05 May 23 2001
# -- Loading package standard
# -- Compiling architecture behavioral of test
# -- Loading package std_logic_1164
# -- Loading package std_logic_arith
# -- Loading package std_logic_unsigned
# -- Loading package vital_timing
# -- Loading package vcomponents
# -- Loading entity test
# ERROR: test.vhd(58): Cannot load design unit: unisim.bufgmux
# Cannot open file:
F:/xilinx_webpack/modeltech_xe/win32xoem/../xilinx/vhdl/unisim/bufgmux/_prim
ary.dat
# ERROR: test.vhd(58): VHDL Compiler exiting
# ERROR: F:/xilinx_webpack/modeltech_xe/win32xoem/vcom failed.
# Error in macro ./test_tb.fdo line 8
# F:/xilinx_webpack/modeltech_xe/win32xoem/vcom failed.
# while executing
# "vcom -skip e -93 -explicit test.vhd"
The section of my code that may be of interest is as follows
component BUFGMUX
port (
I0 : in std_logic;
I1 : in std_logic;
S : in std_logic;
O : out std_logic
);
end component;
and...
U1: BUFGMUX
port map (
I0 => zero, -- insert clock input used when select (S) is Low
I1 => clk, -- insert clock input used when select (S) is High
S => ena, -- insert Mux-Select input
O => bufclk -- insert clock output
);
and ...
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
--
-- synopsys translate_off
library UNISIM;
use UNISIM.VCOMPONENTS.ALL;
-- synopsys translate_on
--
Thanks,
Theron Hicks
Article: 35413Theron Hicks wrote: > I am trying to use a BUFGMUX in Xilinx webpack 4.1 and Modelsim xe 5.5b > (starter) and I get the following message. > > # Model Technology ModelSim XE vcom 5.5b Compiler 2001.05 May 23 2001 > # -- Loading package standard > # -- Compiling architecture behavioral of test > # -- Loading package std_logic_1164 > # -- Loading package std_logic_arith > # -- Loading package std_logic_unsigned > # -- Loading package vital_timing > # -- Loading package vcomponents > # -- Loading entity test > # ERROR: test.vhd(58): Cannot load design unit: unisim.bufgmux > # Cannot open file: > F:/xilinx_webpack/modeltech_xe/win32xoem/../xilinx/vhdl/unisim/bufgmux/_prim > ary.dat > # ERROR: test.vhd(58): VHDL Compiler exiting > # ERROR: F:/xilinx_webpack/modeltech_xe/win32xoem/vcom failed. > # Error in macro ./test_tb.fdo line 8 > # F:/xilinx_webpack/modeltech_xe/win32xoem/vcom failed. > # while executing > # "vcom -skip e -93 -explicit test.vhd" > > The section of my code that may be of interest is as follows > > component BUFGMUX > port ( > I0 : in std_logic; > I1 : in std_logic; > S : in std_logic; > O : out std_logic > ); > end component; > > and... > > U1: BUFGMUX > port map ( > I0 => zero, -- insert clock input used when select (S) is Low > I1 => clk, -- insert clock input used when select (S) is High > S => ena, -- insert Mux-Select input > O => bufclk -- insert clock output > ); > > and ... > > library IEEE; > use IEEE.STD_LOGIC_1164.ALL; > use IEEE.STD_LOGIC_ARITH.ALL; > use IEEE.STD_LOGIC_UNSIGNED.ALL; > > -- > -- synopsys translate_off > library UNISIM; > use UNISIM.VCOMPONENTS.ALL; > -- synopsys translate_on > -- > > Thanks, > Theron HicksArticle: 35414
Having written some teaching materials based on ABEL and XPLA development system
I'm now trying to convert to VHDL and Webpack.
Here's a very introductory ABEL design:
MODULE basic_gates
TITLE 'two-way demultiplexer'
DECLARATIONS
clock, control pin 43,14; "clock, push switch
X, Y pin 16,27; "left, right LEDs
EQUATIONS
X = control & clock;
Y = !control & clock;
END
As an introduction to a different way (behavioural?) of thinking I
point out that there is a when-then-else solution:
EQUATIONS
when (control == 0) then X = clock;
else Y = clock;
END
These both work fine.
In VHDL I can get this to work:
entity basic_gates is
port
(
clock,control : in bit;
X,Y : out bit
);
end basic_gates;
architecture how_it_works of basic_gates is
begin
X <= clock when control = '1' else '0';
Y <= clock when control = '0' else '0';
end how_it_works;
...but this won't:
architecture how_it_works of basic_gates is
begin
process(control,clock)
begin
if control = '1' then X <= clock;
else Y <= clock;
end if;
end process;
end how_it_works;
Am I doing something fundamentally wrong? Why can't I use the if-then-else
syntax except in a process? Is a process appropriate for a combinational
problem? Have I got the right signals in the sensitivity list?
Many thanks.
Article: 35415Does anyone have links to info on prototyping with BGA packages? I'm trying to figure out what tools to buy and what the PCB layout requirements might be for the lager BGA FPGA's. Thanks, -- Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "ecinema"Article: 35416
Hi - Can someone give me a rough speed estimate for the 18-by-18 multipliers in the Virtex II parts? I plan to drive the inputs from block RAM outputs or registers; the outputs will go directly to registers. Enabling the internal pipeline register would be fine, too. In the interests of keeping the cost finite, the target device is a -4 speed grade. I'd experiment with PAR myself, but I'm still waiting for 4.1. Thanks, Bob Perlman Cambrian Design WorksArticle: 35417
You can do RLOCs in VHDL, at least with synplicity and leonardo, and have been
able to for about 2.5 years now. If you couldn't, I wouldn't be using VHDL.
Not only can you put RLOCs in, you can also use user attributes to put in TNMs,
BLKNMs, initial values and whatever else you want. The key for these critical
circuits is to treat the synthesizer as a generator rather than a synthesizer.
Works like a charm.
By doing this for a hierarchical library, you eventually get a set of commonly
used macros that are optimized RPMs that you can instantiate in your RTL code.
That way you get both fast development AND fast performance. I miss the visual
presentation of schematics, but that is about it.
stefaan vanheesbeke wrote:
> hi,
>
> I think it depends so much of the design itself, that you cannot give a
> general rule.
>
> Sometimes, a nice looking top level done in schematic entry is better than
> just some text files. Specially if you are working with more people on a
> project, everyone has a nice overview of the global design.
>
> Sometimes you need the other way. Especially when you cannot enter
> constraints in the HDL code (cfr Ray Andraka). I did a processor 2 years ago
> and the alu was done in schematic, converted to EDIF and then placed and
> routed toghether with the other parts. There was now way to tell the
> synthsise tool to make a fast enough design for me or the pass the RLOC
> constraints to the par tool.
>
> Also a thing to consider : what is the important thing on what part of the
> design : is it the best timing and placement theoretically possible, or the
> fastest development or a mixture of both? I learned to make a working system
> in a reasonable time and with the acceptance of the fact that it can be done
> better, and faster, and nicer, and... but you have to make decisions on what
> is important.
>
> "Duane Hague" <dhague@neo.rr.com> schreef in bericht
> news:MPG.1623f404e41478c3989681@news-server.neo.rr.com...
> > In article <3BB9E8C7.4CA8327D@flukenetworks.com>,
> > mike.treseler@flukenetworks.com says...
> > > Duane Hague wrote:
> > >
> > > > By chance, I happened to have just tried designing a 32-bit
> barrel
> > > > shifter (0-31 shift, 5-bit shift index) in MaxPlus with schematic
> entry
> > > . . .
> > >
> > > > Conclusion: Could this be a nice example of why a designer should
> have
> > > > more than "one arrow in his quiver"?
> > >
> > > Certainly you can't beat packing your own primitives
> > > for speed and gate count.
> > >
> > > But consider that a barrel shifter might be less
> > > than 1% of a large design.
> > >
> > > And you might want to reuse the design in 2 years
> > > on newer devices.
> > >
> > > -- Mike Treseler
> > >
> > To be a bit less subtle, my point was that IMO schematic entry should
> > remain part of the designers tool kit. HDL synthesizers use an "N-bit"
> > modular translation approach because it would be too complex to include
> > optimization for all cases of "input width" versus "architecture element
> > width". I would suggest that the designer needs to be aware of the
> > advantages and disadvantages of each entry method and to select the
> > method most appropriate to each portion of the design. Over many years
> > of experience, I have lost trust in anyone who proposes "the magic
> > answer where one size fits all" (i.e. certain HDL True Believers).
> >
> > With regards to "reuse": If your EDA tools do not support both HDL and
> > schematic entry as well as mixed entry modes; I would argue that you
> > need to consider the use of other EDA tools! I would not be happy with
> > any EDA tools that did not allow more than one mode of design entry.
> >
> > Respectfully,
> > Duane Hague
--
--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: 35418
Martin Rice <jmrice@ntlworld.com> wrote in message
news:e00c15a3.0110031421.7f0ba99b@posting.google.com...
> Having written some teaching materials based on ABEL and XPLA development
system
> I'm now trying to convert to VHDL and Webpack.
> ...
> architecture how_it_works of basic_gates is
> begin
> X <= clock when control = '1' else '0';
> Y <= clock when control = '0' else '0';
> end how_it_works;
> ...but this won't:
>
> architecture how_it_works of basic_gates is
> begin
> process(control,clock)
> begin
> if control = '1' then X <= clock;
Y<='0'; -- ADD THIS
> else Y <= clock;
X<='0'; -- AND THIS
> end if;
> end process;
> end how_it_works;
> Am I doing something fundamentally wrong?
Without the '0' assignments, you have turned X and Y into latches. In
general, if a combinatorial process can execute without assigning a value to
a signal, the synthesizer will infer a latch (and usually issue a warning
also)
> Why can't I use the if-then-else syntax except in a process?
Because by definition in VHDL if-then-else is sequential code and sequential
code is only allowed in a process (or procedure or function).
> Is a process appropriate for a combinational problem?
yes
>Have I got the right signals in the sensitivity list?
yes
Note that your two forms are equivalent for synthesis but in simulation they
will function slightly differently (and "incorrectly") if the signal control
has other values (like 'X' or 'Z').
Check out comp.lang.vhdl and track down the FAQ associated with that ng.
Also any introductory VHDL book should cover these subjects.
Jeff
Article: 35419On Wed, 03 Oct 2001 06:16:53 -0000, hmurray-nospam@megapathdsl.net (Hal Murray) wrote: > >>That is in the nature of DDS. >>Max jitter = one clock period. >>If that is acceptable, go for it. > >Somehow, it seems as though I should be able to get close to >a half clock period. Closer "just" takes more bits of state. > >What am I missing? Another way of looking at this is to think about the output of the NCO as being a square wave at some frequency that has been sampled by the NCO clock. If the frequency of the square wave is the NCO clock divided by an integer, then the sampling process will produce 0 jitter. For most frequencies though, the sampling process produces jitter of up to a clock period. Please take the time to look at the jitter measurements that I posted earlier in this thread. *** There's a simple modification that halves this jitter. It does require a 50% duty cycle clock and one falling edge flip flop though. Email for code. Regards, Allan.Article: 35420
Yes, sorry I found no CPLD Newsgroup. It's the XCR3064XL Coolrunner and I think, the Parallel JTEG Download Cable should function with the 3,3V. And the Software finds the Cable, but can't identify the CPLD. Thanks Martin.Fischer@fzi.de "Magnus Homann" <d0asta@licia.dtek.chalmers.se> schrieb im Newsbeitrag news:ltpu844xa1.fsf@licia.dtek.chalmers.se... > Peter Alfke <peter.alfke@xilinx.com> writes: > > > Before anybody wastes time looking for the part number: > > There never was an XC3064XL. But there is/was an XC3064L, a 3.3-V version of the > > XC3064A. > > Maybe he was referring to the XCR3064XL? > > Homann > -- > Magnus Homann, M.Sc. CS & E > d0asta@dtek.chalmers.seArticle: 35421
So, essentially, what you are saying is that, given I have quite a big design which I DEFINATELY do not want to lose, it would be wise to hold off on upgrading to 4.1 until I have finished with my design? Is there someone here from Xilinx who could give a definitive answer? adrian > It seems that the schematics are not compatible!!! And as the my local > application engineer from AVNET says : there is no conversion program > available, and there will never be a conversion program available. > > The thing is, Xilinx wants everyone to use VHDL and/or Verilog. Here is the > good point, the XST synthesiser has no 'node locked' and or 'time' > restrictions. So I think (and I hope) once installed, you never have to look > again for new license files, ... as for example for the synopsys stuff. > > The bad thing is that I've used synopsys until now and while converting a > project from foundation to ISE, I saw that the syntax to include > constraints(like the contents of a RAM block) in HDL (verilog in my case) is > different with the XST compiler. So you are fucked anyway, either schematic > or HDL is not fully compatible. > > On the other hand, you cannot wait to start using the latest software for > new things, otherwise the gap is getting bigger and bigger. Xilinx wants to > sell mare and more bigger components, so the need bigger and bigger > software. I think Xilinx (and also Altera) wants to go faster to new > technologies than most of their customers, but everyone is forced to follow > them. This is the bat thing about only two really big companys on the top of > the programmable logic mountain. > > See you, > > Stefaan > > > "Richard Dungan" <postmaster@[127.0.0.1]> schreef in bericht > news:fdgmrt4apvaejfmq3ksgmhracbu5fhj9t4@4ax.com... > > Hi all. > > > > I'm running Xilinx Foundation Base Express (the one with VHDL added on). > > I've used this for several years and by remembering to pay for support, > > I've avoided getting drawn into the time-based licence thing. > > > > I received a letter recently from Xilinx, telling me that Foundation > > 4.1i is about to ship. All well and good. > > > > The letter goes to some length to extol the virtues of Xilinx' new ISE > > package, and I'm curious as to the pros and cons of moving over to this. > > > > Things that particularly concern me are: > > > > 1) What are the licence implications? I understand that Foundation is to > > be canned in due course. When it becomes ISE *only* will I suddenly > > be expected to buy a time-based licence? > > > > 2) What kind of support does ISE give to schematic entry? I foresee an > > ongoing need for this (partly driven from outside) for some time to > > come. This may include updates to Foundation projects. > > > > Any opinions would be welcome. > > > > Richard > > > > ------------Richard Dungan------------- > > Radix Electronic Designs, Orpington, UK > > richardATradixDASHdesignDOTcoDOTuk > > --------------------------------------- > >Article: 35422
"Martin Fischer" <Martin.Fischer@fzi.de> writes: > Yes, sorry I found no CPLD Newsgroup. No problem, you're in the right group. > It's the XCR3064XL Coolrunner and I think, the > Parallel JTEG Download Cable should function with > the 3,3V. And the Software finds the Cable, but can't > identify the CPLD. You need either the old XPLA Programmer (available with the 3.1i tools), or the new iMPACT (available with the 4.1i tools). iMPACT is also available as a free download from http://www.support.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=ISE+WebPack I hope this helps. Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 35423
Hi Group My iMPACT program can not establish communication with the cable when trying to reach the JTAG chain. My setup is straightforward: a standard pc with ecp+epp printerport, windows 2000 and the small Virtex2 evaluation board connected to the parallel port. I'm using Xilinx ISE4. The cable, power, etc. are all properly connected. What can be the cause? Do i need to make specific port settings in Windows? thanx in advance, regards, SebastianArticle: 35424
How to use built-in multipliers in virtex-II? Do I need to use any libraries from xilinx? Rgds, visu
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