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
Leon wrote: > On 1 Oct, 18:38, Leon <leon...@btinternet.com> wrote: >> They are having lots of problems with their web site. I was able to >> register OK with Firefox, but didn't get my password, although the >> message said it was being sent. I used their Support facility, and >> they emailed the password manually to me. >> >> They now have schematics and design files for the XC-1 board >> available: >> >> https://support.xmos.com/published/xc1-schematics >> >> Leon >> >> Leon > > I just had an email from my contact at XMOS and mentioned your > problem. Looks like it's working better now. I was able to look at the tutorials online. Pretty interesting, I may get a dev board and play around with it this winter. Thanks for pointing these out. :-)Article: 135451
On Oct 2, 2:08=A0pm, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Thu, 2 Oct 2008 00:51:21 -0700 (PDT), "jack.harv...@googlemail.com" > > <jack.harv...@googlemail.com> wrote: > >Hi, > > >I implemented some single precision floating point units in FPGA (IEEE > >754 fully compliant) to calculate some complex mathematical equations, > >meanwhile, to debug the design modules, I've also got the C source > >code implementing the equations, with all the variables defined in > >single precision floating point. The Verilog code should have the same > >precision as I would expect from the C code. However, I found there > >are differences between the results generated from FPGA and C, the > >precision is about 10**(-5), I suppose this could be caused by round > >off errors. In Verilog, the round off is implemented as "round to the > >nearest (if equal, round to even)", just wondering when it is done in > >C, how the round off works, and how AMD/Intel processor does the round > >off for single precision floating point? > > The Intel processor implements all the rounding modes specified in P754. > How you actually select them is another matter. > > If you haven't already found Prof. Kahan's papers on P754, do so... > > Unfortunately C is a TERRIBLE language for this purpose (working in > single precision floating point); the Visual C compilers especially so; > they take liberties with precision, tending to assume you really want > double precision and silently implementing it for you... > > ... then by forcing data into volatile "float" variables, you finally > get your code to round as expected. Then you decide to abstract over it > with a function, and.... > > C specifies that float arguments passed to functions are automagically > coerced into doubles, so your code automagically breaks again... > > Personally I wouldn't worry about the Verilog unless you are ABSOLUTELY > CERTAIN the C code is doing EXACTLY what you expect... > > it may turn out that the Verilog implementation is accumulating single > precision float rounding errors exactly as it should, while the C code > is assuming you didn't want what you asked for and giving you double > precision instead. > > - Brian > (no I don't much like C; why do you ask? :-) Thanks for all your replies, a little more information which I got today. Both are in single precision floating point, the results are 0x40984d30(Verilog) and 0x40984d36(C), and the two values translate to 4.759422302246094 (Verilog) and 4.759425163269043 (C). And, a better result given by mathematical tool is 4.75942303685175 (regard this as the expected result), the precision is 10**(-6) for both verilog for C, but Verilog has a smaller error, which is quite intriguing, as I would expect the precision not to be worse in C than in Verilog, as the internal computations are done in double-precision floating point in C as pointed out above.Article: 135452
On 2 Oct, 15:07, "Anthony Fremont" <nob...@noplace.net> wrote: > Leon wrote: > > On 1 Oct, 18:38, Leon <leon...@btinternet.com> wrote: > >> They are having lots of problems with their web site. I was able to > >> register OK with Firefox, but didn't get my password, although the > >> message said it was being sent. I used their Support facility, and > >> they emailed the password manually to me. > > >> They now have schematics and design files for the XC-1 board > >> available: > > >>https://support.xmos.com/published/xc1-schematics > > >> Leon > > >> Leon > > > I just had an email from my contact at XMOS and mentioned your > > problem. > > Looks like it's working better now. =A0I was able to look at the tutorial= s > online. =A0Pretty interesting, I may get a dev board and play around with= it > this winter. =A0Thanks for pointing these out. =A0:-) I've just seen on the Xlinkers forum that they will start shipping the XC-1 kits next week. The forum isn't very active yet, but it's worth joining: http://www.xlinkers.org/ LeonArticle: 135453
On 1 Oct, 23:28, LittleAlex <alex.lo...@email.com> wrote: > On Oct 1, 10:44 am, cs_post...@hotmail.com wrote: > > > Project behind schedule... but Quartus decides that today is the day > > to demand a new license file. > > > Which the server has promised but not yet mailed. > > > Don't you just love control-freak software? > > Note to self: =A0Next time don't ignore the "your license will expire in > xx days" messages. They are pretty quick getting the licenses out, as a rule. I usually get mine in a couple of minutes. LeonArticle: 135454
Hi all, I have two questins about xilinx constraints setting. First, for the input constraints, how to create a constraint for "hold time". As I know, OFFSET IN BEFORE and OFFSET IN AFTER are both for the "setup time" contraints. And if there is no constraint for hold time, then how the "hold slack" is computed. Second, how the relationship of the "clock enable" signal and the clock signal is constrainted.Article: 135455
> You can disable the automated insertion of IO symbols with XST. To preven= t > the mapped from throwing away all logic from your design, disable the "tr= im > unconnected signals" in ISE. Hmm doesn't work for me: ERROR:Pack:198 - NCD was not produced. All logic was removed from the design. This is usually due to having no input or output PAD connections in the design and no nets or symbols marked as 'SAVE'. You can either add PADs or 'SAVE' attributes to the design, or run 'map -u' to disable logic trimming in the mapper. For more information on trimming issues search the Xilinx Answers database for "ERROR:Pack:198" and read the Master Answer Record for MAP Trimming Issues. I disabled trim signals and the automatic insertion of IO symbols. > > > On Oct 1, 1:25 am, Andy <jonesa...@comcast.net> wrote: > >> On Sep 30, 2:27 pm, Kevin Neilson > > >> <kevin_neil...@removethiscomcast.net> wrote: > >>> Heiner Litz wrote: > >>>> Hi, > >>>> I want to perform reasonable post place&route timing analysis for so= me > >>>> RTL modules. The modules have a higher pin count as the FPGA itself. > >>>> ISE always tries to map the modules I/Os to specific IO pads, so its > >>>> not possible to make post P&R timing analysis for such (internally > >>>> used) modules. > >>>> The post synthesis timing is unrealistic, so how can I get a timing > >>>> estimation including wire delay for dedicated modules? > >>>> Any ideas? > >>> If the problem is that you don't have enough pins on the device, you > >>> could make sure all the I/O are registered, instruct the synthesizer = not > >>> to add IOB pads, and put syn_keep or syn_preserve (or whatever) HDL > >>> directives on the I/O registers to make sure they don't get pruned. > >>> Then you could have a static timing analysis even though no pins are > >>> connected. =A0You won't be able to easily use this for a simulation, = since > >>> none of the I/Os will come out to top-level ports. =A0-Kevin > >> No, just turn all those external registers into a parallel/serial > >> shift register, and only output the serial output. > > >> Reverse for the input: serial/parallel shift register, and the only > >> chip-level input is the serial input. > > >> A clock, input and output pin; should fit in anything. > > >> AndyArticle: 135456
Heiner Litz wrote:
> I want to perform reasonable post place&route timing analysis for some
> RTL modules. The modules have a higher pin count as the FPGA itself.
Since the complete design fits the pins,
why not run STA on that?
-- Mike Treseler
Article: 135457>Hi all, > I have two questins about xilinx constraints setting. > >First, for the input constraints, how to create a constraint for "hold >time". As I know, OFFSET IN BEFORE and OFFSET IN AFTER are both for the >"setup time" contraints. And if there is no constraint for hold time, then >how the "hold slack" is computed. > >Second, how the relationship of the "clock enable" signal and the clock >signal is constrainted. > I have find the answer for the first question. It's the keyword VALID that is used to define the data valid window. But, anyone got the answer for the second question?Article: 135458
A few years ago I downloaded the WEBPACK for linux. I checked recently in http://www.xilinx.com/support/download/index.htm and it seems the free version is only for windows. Does xilinx stop to give it for free (the linux version).Article: 135459
jack.harvard@googlemail.com wrote: > On Oct 2, 2:08 pm, Brian Drummond <brian_drumm...@btconnect.com> > wrote: (snip on floating point in verilog and C) >>Unfortunately C is a TERRIBLE language for this purpose (working in >>single precision floating point); the Visual C compilers especially so; >>they take liberties with precision, tending to assume you really want >>double precision and silently implementing it for you... Code for the intel x87 floating point processor normally generates extended precision (64 bit significand) results. There are bits to reduce the precision for some, but not all, operations, but it isn't normally changed. >>... then by forcing data into volatile "float" variables, you finally >>get your code to round as expected. Then you decide to abstract over it >>with a function, and.... >>C specifies that float arguments passed to functions are automagically >>coerced into doubles, so your code automagically breaks again... For ANSI C, and with a prototype in scope, float should be passed as float. For varargs they are passed as double. >>Personally I wouldn't worry about the Verilog unless you are ABSOLUTELY >>CERTAIN the C code is doing EXACTLY what you expect... >>it may turn out that the Verilog implementation is accumulating single >>precision float rounding errors exactly as it should, while the C code >>is assuming you didn't want what you asked for and giving you double >>precision instead. > Thanks for all your replies, a little more information which I got > today. Both are in single precision floating point, the results are > 0x40984d30(Verilog) and 0x40984d36(C), and the two values translate to > 4.759422302246094 (Verilog) and 4.759425163269043 (C). And, a better > result given by mathematical tool is 4.75942303685175 (regard this as > the expected result), the precision is 10**(-6) for both verilog for > C, but Verilog has a smaller error, which is quite intriguing, as I > would expect the precision not to be worse in C than in Verilog, as > the internal computations are done in double-precision floating point > in C as pointed out above. Among other causes for wrong results is double rounding. With x87, you can round from 64 bits to 53 and then to 24, giving a different result from the proper rounding from 64 to 24 bits. Also, doing some parts of a calculation with extra precision, but not all, can result in different results. -- glenArticle: 135460
commone wrote:
>> Second, how the relationship of the "clock enable" signal and the clock
>> signal is constrainted.
> I have find the answer for the first question. It's the keyword VALID that
> is used to define the data valid window.
> But, anyone got the answer for the second question?
clock is a clock
clock enable is an input
-- Mike Treseler
Article: 135461>Hi all, > I have two questins about xilinx constraints setting. > >First, for the input constraints, how to create a constraint for "hold >time". As I know, OFFSET IN BEFORE and OFFSET IN AFTER are both for the >"setup time" contraints. And if there is no constraint for hold time, then >how the "hold slack" is computed. > >Second, how the relationship of the "clock enable" signal and the clock >signal is constrainted. > Does ISE treat the "CE" input of a Flip-flop the same as the "D" input during Place&route and Static timing analysis?Article: 135462
>commone wrote: > >>> Second, how the relationship of the "clock enable" signal and the clock >>> signal is constrainted. > >> I have find the answer for the first question. It's the keyword VALID that >> is used to define the data valid window. >> But, anyone got the answer for the second question? > > >clock is a clock >clock enable is an input > > -- Mike Treseler > Thank u Mike! :)Article: 135463
beky4kr@gmail.com wrote: > A few years ago I downloaded the WEBPACK for linux. > I checked recently in http://www.xilinx.com/support/download/index.htm > and it seems the free version is only for windows. > > Does xilinx stop to give it for free (the linux version). They still have the free Linux version, for 32-bit architecture ONLY! If you have a 64-bit system, there apparently is a way to make it work, too. I didn't want to do that much hacking, and we have a site license for the "real thing". JonArticle: 135464
On Thu, 02 Oct 2008 10:43:38 -0800, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >>>... then by forcing data into volatile "float" variables, you finally >>>get your code to round as expected. Then you decide to abstract over it >>>with a function, and.... > >>>C specifies that float arguments passed to functions are automagically >>>coerced into doubles, so your code automagically breaks again... > >For ANSI C, and with a prototype in scope, float should be >passed as float. For varargs they are passed as double. *cough* serves me right for consulting my copy of K&R again. I hear there's a second edition out... you're right of course. But it's a bit alarming that it'll compile without a visible prototype, and silently deliver different results. >> Thanks for all your replies, a little more information which I got >> today. Both are in single precision floating point, the results are >> 0x40984d30(Verilog) and 0x40984d36(C), and the two values translate to >> 4.759422302246094 (Verilog) and 4.759425163269043 (C). And, a better >> result given by mathematical tool is 4.75942303685175 I make Verilog 1.5E-7 (error/correct) and C 4.5E-7, or 3x the error. Which suggests the correct result is 1.5 LSBs greater than the Verilog result. Or alternatively, the best you can achieve is 1/3 of the current error. >Among other causes for wrong results is double rounding. > >With x87, you can round from 64 bits to 53 and then to 24, >giving a different result from the proper rounding >from 64 to 24 bits. > >Also, doing some parts of a calculation with extra precision, >but not all, can result in different results. Yes. At this point there are two aspects to consider: (1) the correctness of the Verilog implementation. This would be easy to check if you had a numerically reliable (not accurate! but correct in single precision) reference implementation to compare against. (2) the importance of errors in the application anyway. (It may be worth using higher precision internally in critical areas). If small errors are tolerable, you might get away with the current Verilog implementation; compare its output against a high accuracy model with acceptable tolerance bounds (e.g. assert an error if abs(worst case error) >= 0.5e-6). If the Verilog implementation must be correct, you will need a reference implementation in which every operation is known to be correct to single precision (the difficult bit, in C!), and test for bitwise identical results. - BrianArticle: 135465
news@rblack01.plus.com wrote: > Hi, > > Does anybody make a standalone (i.e. non PC-based) programmer for > Altera devices? > Our product uses a Cyclone which loads its config from a EPCS1 1-Mbit > EEPROM at power-up. To program the EEPROM in production we are using > a PC running Quartus, and a ByteBlaster. This works OK, but is a bit > cumbersome and prone to error (e.g. operator selects wrong object > file) > > To program the Microchip PICs in the same product we use a fag-packet > sized programmer from www.kanda.com - these are battery powered, data > downloaded via a cable from a PC, the only user interface is one > button and a green/red LED, completely idiot-proof. > > I've been trying to find an equivalent product for Altera devices, > without success. I'm now considering making one for my own use, based > on an MCU + external Flash chip. If I did, would it be worth selling? Commercial programmers will pgm the EPCS1. (one example is eetools ChipMax-2) These typically have a Project file, so you can save the source+device, and reduce operator errors, and a front panel button, so users do not even have to touch the PC... -jgArticle: 135466
Brian Drummond wrote: (snip, I wrote) >>For ANSI C, and with a prototype in scope, float should be >>passed as float. For varargs they are passed as double. > *cough* serves me right for consulting my copy of K&R again. > I hear there's a second edition out... I wonder when the third edition will be out. > you're right of course. But it's a bit alarming that it'll compile > without a visible prototype, and silently deliver different results. Just as Fortran will do without an interface, and for the same reason: backward compatibility. (snip) > At this point there are two aspects to consider: > (1) the correctness of the Verilog implementation. This would be easy to > check if you had a numerically reliable (not accurate! but correct in > single precision) reference implementation to compare against. > (2) the importance of errors in the application anyway. (It may be worth > using higher precision internally in critical areas). The nice thing about verilog implementations is that you can easily add bits, even one or two. That is hard on a processor with fixed sized registers. > If small errors are tolerable, you might get away with the current > Verilog implementation; compare its output against a high accuracy model > with acceptable tolerance bounds > (e.g. assert an error if abs(worst case error) >= 0.5e-6). > If the Verilog implementation must be correct, you will need a reference > implementation in which every operation is known to be correct to single > precision (the difficult bit, in C!), and test for bitwise identical > results. There might be some compilers that will force single precision between every operation. -- glenArticle: 135467
Eric Smith <eric@brouhaha.com> writes: > Kevin Neilson wrote: > > Sure, you can determine that a LUT with a INIT code of FFFE is an > > inverter. > > thutt wrote: > > Can you point me to a reference that shows how to do this? > > Any textbook on digital logic! > > You have a logic circuit with four inputs, with the truth table: > > ABCD Q ABCD Q > ---- - ---- - > 0000 1 1000 1 > 0001 1 1001 1 > 0010 1 1010 1 > 0011 1 1011 1 > 0100 1 1100 1 > 0101 1 1101 1 > 0110 1 1110 1 > 0111 1 1111 0 > > It should be immediately obvious that the circuit is a four-input NAND, and > that if any three inputs are tied high, Q is the inverse of the fourth input. I didn't actually mean the math part, I meant converting the initialization string into something usable. I have, since my query, talked to an actual hardware-type person and he's explained how this stuff works down at the metal, and now I comprehend how to convert the technology netlist into an RTL netlist. Now, it's just a matter of time & will to do it. thutt -- Hoegaarden!Article: 135468
Jon Elson <jmelson@wustl.edu> writes:
> beky4kr@gmail.com wrote:
> > A few years ago I downloaded the WEBPACK for linux.
> > I checked recently in http://www.xilinx.com/support/download/index.htm
> > and it seems the free version is only for windows.
> > Does xilinx stop to give it for free (the linux version).
> They still have the free Linux version, for 32-bit architecture ONLY!
> If you have a 64-bit system, there apparently is a way to make it
> work, too. I didn't want to do that much hacking, and we have a site
> license for the "real thing".
>
> Jon
One could always use vmware on Linux to create a 32-bit VM in which
you can run the Xilinx tools. It works very nicely -- redirect X to
your host computer's ${DISPLAY} setting, and ISE will even appear on
your regular monitor (not inside the VM window).
thutt
--
Hoegaarden!
Article: 135469
Svenn Are Bjerkem <svenn.bjerkem@googlemail.com> writes:
> On Sep 30, 6:01 am, thutt <thutt...@comcast.net> wrote:
> > vlod...@gmail.com writes:
> > > Guys,
> >
<snip>
> > I'm certainly no expert in the field of hardware design, but I've had
> > good luck using the master clock signal and an 'enable' that runs at
> > the desired clock speed. I've successfully used this technique to
> > divide the Spartan 3E 50MHz clock down to 230Khz for serial port
> > transmission.
> >
> > I'd be happy to provide the entity which produces the 'enable' signal
> > and an example of how to use it if you're interested.
>
> please provide,
Svenn,
Since you asked, and since it appears to be something that's not so
easily findable on the net -- at least with my google-fu -- I'm going
to post the sample and the library here rather than in private email.
I hope it doesn't violate any general rules of this newsgroup. I also
hope that if I've done something insanely stupid in the code that
someone more knowledgeable will point that out.
1. the clock divider.
I started out with a clock divider I found by Brian Boorman. The
version I downloaded didn't compile, and I had to make
modifications. After getting it to work, I decided that *I* felt
the code was ugly and could use a little sprucing up to make it more
accessible.
I then used that version for a while until I ran into some clock
issues and I was admonished by my hardware guardian angel that it
would be best to have only a single clock in your design and to use
an 'enable'.
Of course, it's not straightforward how to get an 'enable pulse' to
occur when desired, but only for one cycle of the master clock
signal.
For example, consider a 50MHz master clock (like the Spartan 3E) and
a divided clock of 230,400 Hz. Originally, the clock divider entity
output a wave form that was 230,400Hz - but that would be many, many
clocks at 50MHz. I only wanted ONE pulse at 50 MHz for each
transition of the 230,400 Hz clock. This is accomplished with a
two flip flops (i.e., the normal trick used to cross clock domains)
and a little extra logic. This is implemented using 'shift_reg' and
the assignment to 'clk_enable'.
The 'clock_divisor' generic input is the divisor used to produce the
desired clock. Taking the 50MHz / 230400 Hz example, the divisor is
14. The 230,400 Hz value is a serial port speed. So, the value is
calculated like this:
master clock / desired-bps / special-divisor
50,000,000 / 230,400 / 15
The special divisor was tediously calculated by hand. I won't go
into the details here, but I may someday on
http://www.harp-project.com/.
Below I have an example which will blink the LEDs on the Spartan 3E
board at 1, 10 and 100 Hz, so you'll see another example.
--- begin clock divider ---
-- Copyright (c) 1997 Brian Boorman, Harris RF Communications, Rochester, NY
--
-- Originally code found here:
-- http://www.edn.com/archives/1997/081597/17di_01.htm
--
-- This version of the code is fixed from the original, and then
-- cleaned up in terms of formatting and simplicity, but the original
-- code still is largely intact.
library ieee;
use ieee.std_logic_1164.all;
entity clkdiv_enable is
generic(clock_divisor: natural := 3);
port(clkin : in std_logic; -- 50% Duty Cycle Input Clock
reset : in std_logic; -- Active high reset
clk_enable : out boolean);
end clkdiv_enable;
architecture lms of clkdiv_enable is
-- This subtype will constrain counter width.
subtype divtype_t is natural range 0 to clock_divisor - 1;
constant is_valid : boolean := clock_divisor >= 1;
constant is_passthru : boolean := clock_divisor = 1;
constant is_half : boolean := clock_divisor = 2;
constant is_odd : boolean := (((((clock_divisor / 2) * 2)) =
(clock_divisor - 1)) and
(clock_divisor > 2));
constant is_even : boolean := (((((clock_divisor / 2) * 2)) =
clock_divisor) and
(clock_divisor > 2));
signal enable : std_logic;
signal shift_reg : std_logic_vector(1 downto 0);
signal counter : divtype_t;
signal en_tff : std_logic_vector(boolean'pos(is_odd) downto 0);
signal divisor : std_logic_vector(boolean'pos(is_odd) downto 0);
function std_logic_to_bool(s : std_logic) return boolean is
begin if s = '1' then return true; else return false; end if;
end function std_logic_to_bool;
begin
assert(is_valid)
report "Clock divisor must be a positive number >= 1"
severity failure;
assert(not is_odd)
report "Clock divisor is odd; will result in a combinatorial clock signal"
severity failure;
assert(not is_half)
report "Generating a half-cycle clock"
severity warning;
assert(not is_passthru)
report "Generating a passthrough clock"
severity warning;
assert(not is_even)
report "Generating an even clock"
severity warning;
gOne:
if is_passthru generate
enable <= clkin when reset = '0' else
'0';
end generate;
gTwo: -- generate a T Flip-Flop
if is_half generate
pTwo: process(clkin, reset, divisor(0))
begin
if reset = '1' then
divisor(0) <= '0';
elsif rising_edge(clkin) then
divisor(0) <= not(divisor(0));
end if;
end process;
enable <= divisor(0);
end generate;
gOdd:
if is_odd generate
pOdd: process(clkin, reset, counter)
begin
if reset = '1' then
counter <= 0;
elsif rising_edge(clkin) then
if counter = clock_divisor - 1 then
counter <= 0;
else
counter <= counter + 1;
end if;
end if;
end process;
en_tff(0) <= '1' when counter = 0 else '0';
en_tff(1) <= '1' when counter = (((clock_divisor - 1) / 2) + 1) else '0';
pOddDiv1: process(clkin, reset, en_tff(0), divisor(0))
begin
if reset = '1' then
divisor(0) <= '1';
elsif rising_edge(clkin) then
if en_tff(0) = '1' then
divisor(0) <= not(divisor(0));
end if;
end if;
end process;
pOddDiv2: process(clkin, reset, en_tff(1), divisor(1))
begin
if reset = '1' then
divisor(1) <= '1';
elsif falling_edge(clkin) then
if en_tff(1) = '1' then
divisor(1) <= not(divisor(1));
end if;
end if;
end process;
enable <= divisor(0) xor divisor(1);
end generate;
gEven:
if is_even generate
pEvenDiv: process(clkin, reset, counter)
begin
if reset = '1' then
counter <= 0;
elsif rising_edge(clkin) then
if counter = clock_divisor - 1 then
counter <= 0;
else
counter <= counter + 1;
end if;
end if;
end process;
en_tff(0) <= '1' when ((counter = 0) or
(counter = ((clock_divisor / 2) - 1)) )
else '0';
pEvenDiv1: process(clkin, reset, en_tff(0), divisor(0))
begin
if reset = '1' then
divisor(0) <= '0';
elsif rising_edge(clkin) then
if en_tff(0) = '1' then
divisor(0) <= not(divisor(0));
end if;
end if;
end process;
enable <= divisor(0);
end generate;
shift_reg <= enable & shift_reg(1) when rising_edge(clkin);
clk_enable <= std_logic_to_bool(shift_reg(1) and not shift_reg(0));
end lms;
--- end clock divider ---
2. Constraints file
Below is the constraint file which assigns the LEDs to my divided
clocks. If you're not using Xilinx software, you'll have to come up
with your own constraints.
-- begin UCF file ---
# This file is part of the Harp Project.
# Copyright (c) 2007, 2008 Taylor Hutt, Logic Magicians Software
# http://www.harp-project.com/
#
# This program is free software: you can redistribute it and/or
# modify it under the terms of the GNU General Public License as
# published by the Free Software Foundation, either version 3 of the
# License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
#
NET "CLK_50MHZ" LOC = "C9" | IOSTANDARD = LVCMOS33 ;
NET "CLK_50MHZ" PERIOD = 20.0ns HIGH 40%;
NET "CLK_1HZ" LOC = "F12" | IOSTANDARD = LVTTL | SLEW = SLOW | DRIVE = 8 ;
NET "CLK_10HZ" LOC = "E12" | IOSTANDARD = LVTTL | SLEW = SLOW | DRIVE = 8 ;
NET "CLK_100HZ" LOC = "E11" | IOSTANDARD = LVTTL | SLEW = SLOW | DRIVE = 8 ;
--- end UCF file ---
3. Sample Design -- Blink LEDs
Finally, a simple example that I just cooked up that will blink some
LEDs on the Xilinx board at 1, 10 and 100Hz.
--- begin Sample VHDL ---
-- This file is part of the Harp Project.
-- Copyright (c) 2007, 2008 Taylor Hutt, Logic Magicians Software
-- http://www.harp-project.com/
--
-- This program is free software: you can redistribute it and/or
-- modify it under the terms of the GNU General Public License as
-- published by the Free Software Foundation, either version 3 of the
-- License, or (at your option) any later version.
--
-- This program is distributed in the hope that it will be useful, but
-- WITHOUT ANY WARRANTY; without even the implied warranty of
-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-- General Public License for more details.
--
-- You should have received a copy of the GNU General Public License
-- along with this program. If not, see <http://www.gnu.org/licenses/>.
--
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity main is
Port (CLK_50MHZ : in STD_LOGIC;
CLK_100HZ : out STD_LOGIC;
CLK_10HZ : out STD_LOGIC;
CLK_1HZ : out STD_LOGIC);
end main;
architecture Behavioral of main is
signal output_1Hz : std_logic := '0';
signal output_10Hz : std_logic := '0';
signal output_100Hz : std_logic := '0';
signal enable_1Hz : boolean;
signal enable_10Hz : boolean;
signal enable_100Hz : boolean;
begin
blink_1Hz : process(CLK_50MHZ, enable_1Hz)
begin
if enable_1Hz then
if rising_edge(CLK_50MHZ) then
output_1Hz <= not output_1Hz;
end if;
end if;
end process blink_1Hz;
blink_10Hz : process(CLK_50MHZ, enable_10Hz)
begin
if enable_10Hz then
if rising_edge(CLK_50MHZ) then
output_10Hz <= not output_10Hz;
end if;
end if;
end process blink_10Hz;
blink_100Hz : process(CLK_50MHZ, enable_100Hz)
begin
if enable_100Hz then
if rising_edge(CLK_50MHZ) then
output_100Hz <= not output_100Hz;
end if;
end if;
end process blink_100Hz;
one_hz: entity clkdiv_enable -- 1 Hz
generic map (clock_divisor => 50000000)
port map (clkin => CLK_50MHZ, reset => '0', clk_enable => enable_1HZ);
ten_hz: entity clkdiv_enable -- 10 Hz
generic map (clock_divisor => 5000000)
port map (clkin => CLK_50MHZ, reset => '0', clk_enable => enable_10HZ);
one_hundred_hz: entity clkdiv_enable -- 100 Hz
generic map (clock_divisor => 500000)
port map (clkin => CLK_50MHZ, reset => '0', clk_enable => enable_100HZ);
CLK_100HZ <= output_100Hz;
CLK_10HZ <= output_10Hz;
CLK_1HZ <= output_1Hz;
end behavioral;
--- end Sample VHDL ---
Keep in mind that I'm not a hardware guy! I'm a low-level software
guy who's learning hardware. So, there could very well be things that
I've done that no sane hardware engineer would actually do. Please be
gentle in critiquing this work. I do however, think that my version
of the clock divider is definitely easier to read.
thutt
---
Hoegaarden!
Article: 135470Jon Elson <jmelson@wustl.edu> wrote: >beky4kr@gmail.com wrote: >> A few years ago I downloaded the WEBPACK for linux. >> I checked recently in http://www.xilinx.com/support/download/index.htm >> and it seems the free version is only for windows. >> >> Does xilinx stop to give it for free (the linux version). >They still have the free Linux version, for 32-bit architecture ONLY! >If you have a 64-bit system, there apparently is a way to make it work, >too. I didn't want to do that much hacking, and we have a site license >for the "real thing". I've not tried this because I'm still on 32-bits, but I understand that you need to install the 64-bit distro's 32-bit compatibility libraries. As to how easy the free Webpack for Linux is to get working in general, you might need to do a *little* hacking to get it to work, if my experience of installing it on Mandriva 2006 a couple of years back is anything to go by... ...as shown in section 5 here: http://no.gentoo-wiki.com/Talk:HOWTO_Xilinx/Archive_1 ...which lists the deviations from the main HOWTO (for Gentoo) here: http://no.gentoo-wiki.com/Xilinx_ISE_WebPACK Once I got it running though, it was quite robust. -- Dave FarranceArticle: 135471
Hi all, I've got a design with that interfaces to a wide (128 bit) DDR2 data bus using a V5. I'm currently using the DCI feature to terminate all of my signals, however because there are so many the power consumption is unacceptably high. I notice that a new IO standard has recently crept into the documentation: SSTL18_II_T_DCI. Although the documentation on this is lacking, it looks like this is supposed to remove the termination when performing writes. However, when I tried to use it in my design, implementation failed because apparently I can't mix DIFF_SSTL18_II_DCI and SSTL18_II_T_DCI in the same bank. Am I missing something here?? The Xilinx MIG design mandates that data strobes and DQ lines must be in the same bank in order to make use of the buffio feature. If the two standards can't be mixed then SSTL18_II_T_DCI is effectively useless. Has anyone had any experience with using this new standard? cheers RobArticle: 135472
On Oct 1, 11:57=A0pm, "Greg Daughtry" <greg.daugh...@xilinx.com> wrote:
> Rob,
>
> Can you post a snippet of the failing path trace from TWR? =A0Is the cloc=
k
> requirement 4X of the TS_SYS_CLK timespec as this multicycle exception is
> indicating? =A0When you say the constraint is being ignored, what exactly=
do
> you mean? =A0Are you looking for a header for the TS_MC_PHY_INIT_DATA_SEL=
_0,
> or are you seeing violations on paths that start from the
> */u_phy_init/u_ff_phy_init_data_sel instance?
>
> 'Greg
>
> Bring up this design in PlanAhead and search for the instances to make su=
re
> nothing simply like hierarchy separators is messing up the constraint?
>
> 'Greg
>
> "Rob" <BertyBoos...@googlemail.com> wrote in message
>
> news:014cfdc3-140e-49aa-aa0c-d2c5f76d1f7f@a1g2000hsb.googlegroups.com...
>
> > Hi all,
>
> > I'm having problems with ISE seemingly ignoring timing constraints set
> > in the UCF file. One of the constraints ignored comes from Xilinx's
> > MIG tool and looks like this:
>
> > INST "*/u_phy_init/u_ff_phy_init_data_sel" TNM =3D
> > "TNM_PHY_INIT_DATA_SEL";
> > TIMESPEC "TS_MC_PHY_INIT_DATA_SEL_0" =3D FROM "TNM_PHY_INIT_DATA_SEL" T=
O
> > FFS
> > "TS_SYS_CLK" * 4;
>
> > I'm not getting any errors, such as unable to locate nets, rather the
> > constraint seems ignored and looking in the timing report it is these
> > very paths that are failing (by a long way). I thought that if the
> > target nets don't exist then you get a translate error.
>
> > I am using partitions in the design. I've tried to do a build after a
> > "clean up project files" and the constraint is still ignored.
>
> > Any ideas?
>
> > Rob
Hi Greg,
Here's a snippet from the TWR file showing one of the failing paths:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
Timing constraint: TS_infastructure0_mem_clk_out_901 =3D PERIOD
TIMEGRP
"infastructure0_mem_clk_out_901" TS_infastructure0_dcm0_clkfx1
PHASE
1.25 ns HIGH 50%;
1622 paths analyzed, 1354 endpoints analyzed, 513 failing endpoints
513 timing errors detected. (513 setup errors, 0 hold errors)
Minimum period is 10.276ns.
---------------------------------------------------------------------------=
-----
Slack: -1.319ns (requirement - (data path - clock
path skew + uncertainty))
Source: memory_domain0/u_ddr2_top/u_mem_if_top/
u_phy_top/u_phy_init/u_ff_phy_init_data_sel (FF)
Destination: memory_domain0/u_ddr2_top/u_mem_if_top/
u_phy_top/u_phy_write/wdf_data_r_102 (FF)
Requirement: 1.250ns
Data Path Delay: 2.030ns (Levels of Logic =3D 1)
Clock Path Skew: -0.234ns (2.558 - 2.792)
Source Clock: mem_clk_div2 rising at 0.000ns
Destination Clock: mem_clk90 rising at 1.250ns
Clock Uncertainty: 0.305ns
Clock Uncertainty: 0.305ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2
+ PE
Total System Jitter (TSJ): 0.070ns
Total Input Jitter (TIJ): 0.000ns
Discrete Jitter (DJ): 0.300ns
Phase Error (PE): 0.120ns
Maximum Data Path: memory_domain0/u_ddr2_top/u_mem_if_top/u_phy_top/
u_phy_init/u_ff_phy_init_data_sel to memory_domain0/u_ddr2_top/
u_mem_if_top/u_phy_top/u_phy_write/wdf_data_r_102
Location Delay type Delay(ns) Physical
Resource
Logical
Resource(s)
-------------------------------------------------
-------------------
SLICE_X42Y43.CQ Tcko 0.375 memory_domain0/
u_ddr2_top/u_mem_if_top/u_phy_top/phy_init_data_sel
memory_domain0/
u_ddr2_top/u_mem_if_top/u_phy_top/u_phy_init/u_ff_phy_init_data_sel
SLICE_X43Y45.C5 net (fanout=3D282) 0.546 memory_domain0/
u_ddr2_top/u_mem_if_top/u_phy_top/phy_init_data_sel
SLICE_X43Y45.C Tilo 0.086 memory_domain0/
u_ddr2_top/u_mem_if_top/u_phy_top/wr_data_rise<19>
memory_domain0/
u_ddr2_top/u_mem_if_top/u_phy_top/u_phy_write/
wdf_data_r_mux0001<101>11
SLICE_X43Y50.SR net (fanout=3D27) 0.575 memory_domain0/
u_ddr2_top/u_mem_if_top/u_phy_top/u_phy_write/N01
SLICE_X43Y50.CLK Tsrck 0.448 memory_domain0/
u_ddr2_top/u_mem_if_top/u_phy_top/wr_data_rise<41>
memory_domain0/
u_ddr2_top/u_mem_if_top/u_phy_top/u_phy_write/wdf_data_r_102
-------------------------------------------------
---------------------------
Total 2.030ns (0.909ns logic,
1.121ns route)
(44.8% logic,
55.2% route)
I don't have Planahead (webpack only), but if I open the design up in
FPGA Editor I can find the named source register (as a BEL in a
slice). In the TWR file and in the FPGA Editor the path seems to
correctly match the constraint path.
Rob
Article: 135473On Thu, 02 Oct 2008 19:14:28 -0800, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >Brian Drummond wrote: >> At this point there are two aspects to consider: ... >> (2) the importance of errors in the application anyway. (It may be worth >> using higher precision internally in critical areas). > >The nice thing about verilog implementations is that you >can easily add bits, even one or two. That is hard on a >processor with fixed sized registers. Verilog and VHDL both. How well would Verilog work for writing a high level model using actual floats (not synthesisable), for comparison with the hardware implementation? Make the testbench self-checking without external files. That is the obvious approach to me in VHDL, but I don't know if it would transfer to Verilog. However it is also not immune to problems of precision; most VHDL implementations I've come across use double precision but it isn't guaranteed. (So the testbench must also check itself!) >> If the Verilog implementation must be correct, you will need a reference >> implementation in which every operation is known to be correct to single >> precision (the difficult bit, in C!), and test for bitwise identical >> results. > >There might be some compilers that will force single precision >between every operation. That would be useful. Otherwise you have to force the conversion manually; possible but unnecessarily hard work. - BrianArticle: 135474
On Fri, 03 Oct 2008 08:03:10 GMT, Dave Farrance <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk> wrote: >Jon Elson <jmelson@wustl.edu> wrote: > >>beky4kr@gmail.com wrote: >>> A few years ago I downloaded the WEBPACK for linux. >>> I checked recently in http://www.xilinx.com/support/download/index.htm >>> and it seems the free version is only for windows. >>> >>> Does xilinx stop to give it for free (the linux version). >>They still have the free Linux version, for 32-bit architecture ONLY! >>If you have a 64-bit system, there apparently is a way to make it work, >>too. I didn't want to do that much hacking, and we have a site license >>for the "real thing". > >I've not tried this because I'm still on 32-bits, but I understand that >you need to install the 64-bit distro's 32-bit compatibility libraries. That's what I did (on OpenSuse 11 64-bit) and it worked. I also needed to disable the abort-on-Linux64 test in the "Setup" shell script, on the basis that this test didn't know about the 32-bit compatibility libraries, but that was trivial. >As to how easy the free Webpack for Linux is to get working in general, >you might need to do a *little* hacking to get it to work, if my >experience of installing it on Mandriva 2006 a couple of years back is >anything to go by... Other than the above; I didn't have to do anything. Other distributions may vary. (Caveat: I haven't tried installing USB cables yet) >Once I got it running though, it was quite robust. Agreed. - Brian
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