Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search

Messages from 39725

Article: 39725
Subject: Re: Virtex-II and SDRAM Controller at 133MHz
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sun, 17 Feb 2002 19:04:38 +0000
Links: << >>  << T >>  << A >>


rickman wrote:

> Ray,
>
> I would like to draw on your experience if I can. I am looking at doing
> a SDRAM and SBSRAM interface in an XC2SE chip and would like to get an
> idea of what speed grade I will need. Turns out that the DSP chip will
> only support up to 100 MHz on the memory bus so I won't have to push the
> speed much. Will this be easy on the slowest speed grade which seems to
> be a -6? Since there only seem to be two speed grades at this time, I
> don't expect to see that much difference (and no industrial in the -7).
> I can't tell from the data sheet as it does not have data for the -7 yet
> (even though I can buy the parts).
>
> From your experience will a 100 MHz SDRAM interface be easy in a
> XC2S200E-6 ?
>

Rickman,

If I might give my experience -

I've got 100MHz working in an XCV600E-6 with only the auto P&R tools and (almost) purely
synthesised logic - only a couple of places where I've had to instantiate MUXF5s + a lot
of ``syn_keep'' constraints to tell Synplify what to do. For us low latency is vital,
latency from our MIPS CPU's start of cycle strobe to the first read dataum back at the
CPU is 10 clocks. To put this into context the best latency I've seen for an ASIC
controller is 9. If the SpartanIIE timing is the same as the original Virtex-E its
doable but not easy without floorplanning esp. if the device useage is high.

I'm now pushing on to the 133MHz goal in a -7, I've been keeping floorplanning in
reserve for this.


Article: 39726
Subject: Re: Handel-C, System-C, Formal verification ???
From: "Seb" <someone@microsoft.com>
Date: Sun, 17 Feb 2002 20:25:57 +0100
Links: << >>  << T >>  << A >>

Did you use the Celoxica software with Handel-C?
I always thought it produced EDIF instead of VHDL output.

cheers,
Seb

"z.karim" <z.karim@attbi.com> wrote in message
news:DyGb8.74623$Pz4.345996@rwcrnsc53...
> Formal verification is generally used to verify gate level netlists
> are equivalent and is used when designing ASICs.  I think of
> formal verification at the HDL level as doing simulation equivalence
> checks.  If you are converting an algorithm written for a CPU to a
> hardware algorithm, I would look at the size of the design as the
> determining factor.  As for all projects, budget, schedule, manpower
> all are taken into consideration.
>
> If the algorithm is large and you can afford to purchase a
> software package like Handel-C, I would go for it.  It is a cost effective
> way of getting what you need.  It does have the capability of spitting
> out VHDL so you can simulate your result; don't expect to be able
> decipher what hardware was generated by looking at the VHDL code.
> The one nice thing we noticed using the Handel-C was that we
> could do a heck of a lot more architecture modifications in the same
> amount of time it would have taken in VHDL.  Also, we were able to
> convert the ANSI-C to Handel-C in 1/30th the time it took to go to VHDL.
>
> As far as determining what speed at which the design runs,
> you have to place and route the design immediately to get the speed at
> which it will run.  Handel-C has all the constructs to allow you to
dictate
> the architecture; it just takes a couple days to get the feel for how it
> generates hardware.  I have used it and have been happy with the
> results: easily passing 100MHz in Spartan II and 200MHz in Virtex II.
>
> We have used SystemC before also, but just for modeling and not
> for hardware generation.  It was simple to use also, but we didn't want
> to buy the synthesizers from Adelante or Synopsys.  Again though, it
> was a heck of a lot easier converting the C algorithms to usable
> code rather than converting it to VHDL.
>
> good luck
>
> "Phil Hays" <spampostmaster@attbi.com.com> wrote in message
> news:3C6EA440.ED3E96D3@attbi.com.com...
> >
> > My current employer has an application where I might want to use one of
> the "C
> > for hardware" type languages.  Basically, there is a sizable chunk of
> ANSI-C
> > code that might need to be put into hardware to improve system
> performance.
> > Before this needs to be started, and it is not clear yet if it truly
does
> need
> > to be done, I'd like to learn more.  Methods for doing this might might
be
> to
> > convert this C code into hardware-c (Handel-C or System-C), or to hand
> convert
> > the C into VHDL, and then verify the conversion by simulation (read lots
> of
> > effort) or to hand convert the C into VHDL and then verify the
conversion
> by
> > some "formal verification" method.
> >
> > The first alternative brings up a bunch of issues.  The tools are fairly
> new: it
> > seems slightly unlikely to me that "pushing the envelope" type hardware
> could be
> > built.  Is this true?  I sat in a Celoxica sales pitch, and the examples
> given
> > were running at 40 MHz or so.  Sorry, but that's not impressive: the
parts
> can
> > easily do 66MHz+ with very little detailed effort, with a high level
VHDL
> (or
> > Verilog) design and almost push-button flow, and 133Mhz, while it does
> take more
> > effort just isn't that hard.  The tools don't appear have features
needed
> to
> > push the design to higher speeds, such as a schematic viewer to quickly
> answer
> > the question, what did my code build into?  I don't know what sort of
> support in
> > any of the "hardware-C" tools for physical design, is there any?  The
> users (me
> > for example) don't understand the whole process: I can read C and
> eventually
> > understand what it's doing, I've written some C code, but I don't have
> > experience in translating ANSI-C into hardware-C or in writing hardware
C.
> How
> > hard is this to learn?  How hard is this to learn to do well?  Meaning
how
> hard
> > is it to produce close to minimum sized hardware that runs fast?
> >
> > Then there is the question of the different variations of hardware-C.
> Opinions
> > on which is best?  (Cue in the VHDL vs Verilog flame war part 2)
> >
> > The second alternative I understand how to do, it is just work, and
there
> is
> > absolutely nothing wrong with that if it's the best option, yet I'd
rather
> do it
> > faster and easier, or faster and fewer bugs...
> >
> > The third alternative is formal verification.  I have no experience in
> such
> > tools, so does anyone have experience, opinions (or both) on the
question
> of
> > would this help to produce FPGA hardware that matches the original C?
> >
> >
> > --
> > Phil Hays
>
>



Article: 39727
Subject: Re: Virtex-II and SDRAM Controller at 133MHz
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 17 Feb 2002 15:55:15 -0500
Links: << >>  << T >>  << A >>
Thanks for the insight. My design is not connecting a micro to the RAM,
it is a DMA controller from IO devices to/from SDRAM. So the latency is
not as large of an issue. I will be moving data in blocks of at least 8
words and maybe as many as 32, so the latency won't be a huge impact on
the total bus usage time. I will want to minimize the time the DSP is
kicked off the bus to transfer blocks. Otherwise, it is not an issue. 

This is working with a 150 MHz DSP and I was surprized to find that the
external memory interface will only run up to 100 MHz. I was looking at
using 133 or 150 MHz memory. I guess I will be able to use the cheap
stuff. 

I have worked with SDRAM before, but we were only running at 33 MHz (PCI
bus speed). That was an XC4000XL IIRC. 33 MHz was no problem and the
rest of the circuit running at 50 MHz was no problem. I did basic
floorplanning for the large blocks (mux/demux, FIFO, memory interface)
and it worked without problems. 

There was one place where I was muxing a clock through the chip (not
used internally) and I needed a very fast route from the CLB to the IOB
next to it. The software could not seen the find the optimal route and I
always had to hand route that one path to save that extra half nS. It
acutally was not too bad. The chip editor was pretty easy to use and
there were never any other signals in the way. 

Based on what you are saying, I expect with a little floorplanning I
should have no trouble at 100 MHz. Thanks.




Rick Filipkiewicz wrote:
> 
> rickman wrote:
> 
> > Ray,
> >
> > I would like to draw on your experience if I can. I am looking at doing
> > a SDRAM and SBSRAM interface in an XC2SE chip and would like to get an
> > idea of what speed grade I will need. Turns out that the DSP chip will
> > only support up to 100 MHz on the memory bus so I won't have to push the
> > speed much. Will this be easy on the slowest speed grade which seems to
> > be a -6? Since there only seem to be two speed grades at this time, I
> > don't expect to see that much difference (and no industrial in the -7).
> > I can't tell from the data sheet as it does not have data for the -7 yet
> > (even though I can buy the parts).
> >
> > From your experience will a 100 MHz SDRAM interface be easy in a
> > XC2S200E-6 ?
> >
> 
> Rickman,
> 
> If I might give my experience -
> 
> I've got 100MHz working in an XCV600E-6 with only the auto P&R tools and (almost) purely
> synthesised logic - only a couple of places where I've had to instantiate MUXF5s + a lot
> of ``syn_keep'' constraints to tell Synplify what to do. For us low latency is vital,
> latency from our MIPS CPU's start of cycle strobe to the first read dataum back at the
> CPU is 10 clocks. To put this into context the best latency I've seen for an ASIC
> controller is 9. If the SpartanIIE timing is the same as the original Virtex-E its
> doable but not easy without floorplanning esp. if the device useage is high.
> 
> I'm now pushing on to the 133MHz goal in a -7, I've been keeping floorplanning in
> reserve for this.

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 39728
Subject: Faster designs
From: "Craig Ward" <ccward@waitrose.com>
Date: Mon, 18 Feb 2002 02:06:31 -0000
Links: << >>  << T >>  << A >>
Hi,

Can anyone give me advice on how to improve my clock speed in my design.  I
am using timing constraints before you ask!!.
The chip is a Virtex2000E and I am using synplify and the latest Xilinx PAR
(ise 4.1etc).  The delays in my design appear to be caused by a few long
nets
(fan out 1 etc).  There is lots of free space on the chip so this is not a
problem.  My target speed is 6.25ns period and the best I can get to is 7ns
etc with par effort at maximum.  I have tried re-entrant routing with no
success.

The design is still being updated and added to so can anyone tell me how I
can get better par in general ?  I would imagine that manual placement would
give me better results in theory but then each time i changed the design I
would have to repeat this process??  Help!

Cheers
Craig



Article: 39729
Subject: Do I need to install software in order to use Multilinx?
From: "X. Q." <qijun@okigrp.com.sg>
Date: Mon, 18 Feb 2002 11:29:28 +0800
Links: << >>  << T >>  << A >>
Do I need to install any driver or software in order to use Multilinx?
Where can I find a driver for Multilinx, if it has one...


--
Best Regards,
Qijun.

********************************************************************
Xu Qijun
Design Engineer, RFIC Group
OKI Techno Centre (S) Pte Ltd
20 Science Park Rd, #02-06/10
Teletech Park,Science Park II,
Singapore  117674
DID: 7707049 Fax: 7792382



Article: 39730
Subject: Edge selection with RAM
From: dottavio@ised.it (Antonio)
Date: 17 Feb 2002 23:43:01 -0800
Links: << >>  << T >>  << A >>
Maybe until now I did not understand many important things, for
example I've the famous
BlockRAM CORE v. 4.0 for it I choose to use the negative front 'cause
I use it in all the rest
of my circuit, the results in terms of speed are ok, almost 100MHz on
XCV1K-4 but in term of
simulation the result is really bad, it is :

# : WARNING: */RAMB4_S1 SETUP High VIOLATION ON ADDR(8) WITH RESPECT
TO CLK;
# :   Expected := 0.01 ns; Observed := 0 ns; At : 1275 ns
# : Time: 1275 ns,  Iteration: 3,  Instance: /U1/U2/U2/B13.
# : WARNING: */RAMB4_S1 SETUP Low VIOLATION ON ADDR(7) WITH RESPECT TO
CLK;
# :   Expected := 0.01 ns; Observed := 0 ns; At : 1275 ns
# : Time: 1275 ns,  Iteration: 3,  Instance: /U1/U2/U2/B13.

and really many other similar warnings, but let's try to understand
what the error say,
the problem is that the clock and the address change on the same time
while from data_sheets
seems that the address must arrive a little bit before 0.01ns.

The only rimedy I know is to change the operating edge of the ram so
now the address change on
negative edge of the clock and the ram work on positive edge. Now the
simulation it's ok but
the speed on FPGA is reduced to 45MHz. 

Naturally I need 100MHz and a simulation working fine, it is possible
to obtain this ??

Article: 39731
Subject: Some problem initializing a RAMB4S1
From: dottavio@ised.it (Antonio)
Date: 17 Feb 2002 23:44:31 -0800
Links: << >>  << T >>  << A >>
With Aldec I arrange the following RAM structure based on twelve
RAMB4S1, the simulation it's ok,
but when I use this file in Xilinx I've the following error from
ModelSim :

# ERROR: Could not open library virtex at virtex: No such file or
directory
# ERROR: RAM_12x4096.vhd(27): Library virtex not found.

OK, I'll try to survive infact XST arrange a black box for it and then
at the end of the
implementation I can see used the RAMB4S1, the problem is that it does
not take the initialization
values so I've zeros in any location. Can you help me to find the
errors and possibly maintaining
the possibility to simulate the project in Aldec ?

Here's the memory structure :

---------------------------------------------------------------------------------------------------
-- Design unit header --
library IEEE;
use IEEE.std_logic_1164.all;


-- other libraries declarations
-- synopsys translate_off 
library VIRTEX;
library IEEE;
use IEEE.vital_timing.all;
-- synopsys translate_on 

entity RAm is
  port(
       clk : in std_ulogic;
       ADDR : in STD_LOGIC_VECTOR(11 downto 0);
       dout : out STD_LOGIC_VECTOR(11 downto 0)
  );
end RAm;

architecture RAm of RAm is

---- Component declarations -----

component RAMB4_S1
-- synopsys translate_off
  generic(
       INIT_00 : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
       INIT_01 : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
       INIT_02 : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
       INIT_03 : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
       INIT_04 : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
       INIT_05 : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
       INIT_06 : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
       INIT_07 : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
       INIT_08 : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
       INIT_09 : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
       INIT_0A : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
       INIT_0B : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
       INIT_0C : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
       INIT_0D : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
       INIT_0E : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
       INIT_0F : BIT_VECTOR :=
X"0000000000000000000000000000000000000000000000000000000000000000";
       InstancePath : STRING := "*";
       MsgOn : BOOLEAN := True;
       TimingChecksOn : BOOLEAN := True;
       Xon : BOOLEAN := True;
       thold_ADDR_CLK_negedge_posedge : VitalDelayArrayType(11 downto
0) := (others => 0.01 ns);
       thold_ADDR_CLK_posedge_posedge : VitalDelayArrayType(11 downto
0) := (others => 0.01 ns);
       thold_DI_CLK_negedge_posedge : VitalDelayArrayType(0 downto 0)
:= (others => 0.01 ns);
       thold_DI_CLK_posedge_posedge : VitalDelayArrayType(0 downto 0)
:= (others => 0.01 ns);
       thold_EN_CLK_negedge_posedge : VitalDelayType := 0.01 ns;
       thold_EN_CLK_posedge_posedge : VitalDelayType := 0.01 ns;
       thold_RST_CLK_negedge_posedge : VitalDelayType := 0.01 ns;
       thold_RST_CLK_posedge_posedge : VitalDelayType := 0.01 ns;
       thold_WE_CLK_negedge_posedge : VitalDelayType := 0.01 ns;
       thold_WE_CLK_posedge_posedge : VitalDelayType := 0.01 ns;
       tipd_ADDR : VitalDelayArrayType01(11 downto 0) := (others =>
(0.0 ns,0.0 ns));
       tipd_CLK : VitalDelayType01 := (0.0 ns,0.0 ns);
       tipd_DI : VitalDelayArrayType01(0 downto 0) := (others => (0.0
ns,0.0 ns));
       tipd_EN : VitalDelayType01 := (0.0 ns,0.0 ns);
       tipd_RST : VitalDelayType01 := (0.0 ns,0.0 ns);
       tipd_WE : VitalDelayType01 := (0.0 ns,0.0 ns);
       tpd_CLK_DO : VitalDelayArrayType01(0 downto 0) := (others =>
(0.10000000000000001 ns,0.10000000000000001 ns));
       tpw_CLK_negedge : VitalDelayType := 0.01 ns;
       tpw_CLK_posedge : VitalDelayType := 0.01 ns;
       tsetup_ADDR_CLK_negedge_posedge : VitalDelayArrayType(11 downto
0) := (others => 0.01 ns);
       tsetup_ADDR_CLK_posedge_posedge : VitalDelayArrayType(11 downto
0) := (others => 0.01 ns);
       tsetup_DI_CLK_negedge_posedge : VitalDelayArrayType(0 downto 0)
:= (others => 0.01 ns);
       tsetup_DI_CLK_posedge_posedge : VitalDelayArrayType(0 downto 0)
:= (others => 0.01 ns);
       tsetup_EN_CLK_negedge_posedge : VitalDelayType := 0.01 ns;
       tsetup_EN_CLK_posedge_posedge : VitalDelayType := 0.01 ns;
       tsetup_RST_CLK_negedge_posedge : VitalDelayType := 0.01 ns;
       tsetup_RST_CLK_posedge_posedge : VitalDelayType := 0.01 ns;
       tsetup_WE_CLK_negedge_posedge : VitalDelayType := 0.01 ns;
       tsetup_WE_CLK_posedge_posedge : VitalDelayType := 0.01 ns
  );
-- synopsys translate_on
  port (
       ADDR : in STD_LOGIC_VECTOR(11 downto 0);
       CLK : in std_ulogic;
       DI : in STD_LOGIC_VECTOR(0 downto 0);
       EN : in std_ulogic;
       RST : in std_ulogic;
       WE : in std_ulogic;
       DO : out STD_LOGIC_VECTOR(0 downto 0)
  );
end component;

----     Constants     -----
constant VCC_CONSTANT   : STD_LOGIC := '1';
constant GND_CONSTANT   : STD_LOGIC := '0';

---- Signal declarations used on the diagram ----

signal GND : STD_LOGIC;
signal VCC : STD_LOGIC;

---- Configuration specifications for declared components 

-- synopsys translate_off
for U1 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
-- synopsys translate_off
for U10 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
-- synopsys translate_off
for U11 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
-- synopsys translate_off
for U12 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
-- synopsys translate_off
for U2 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
-- synopsys translate_off
for U3 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
-- synopsys translate_off
for U4 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
-- synopsys translate_off
for U5 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
-- synopsys translate_off
for U6 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
-- synopsys translate_off
for U7 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
-- synopsys translate_off
for U8 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on
-- synopsys translate_off
for U9 : RAMB4_S1 use entity VIRTEX.RAMB4_S1;
-- synopsys translate_on

begin

----  Component instantiations  ----

U1 : RAMB4_S1
-- synopsys translate_off
  generic map (
       INIT_00 => X"f0c33cf0f0f00f0ff0f00f0f0f3cc30ffc03fcc003fc033ffcc03fc0033fc03f",
       INIT_01 => X"000000000000000000000000000000006a52a92aaa6aa5a995a5565554954a56",
       INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_04 => X"ffcccc33f3cccc33cc3333cfcc3333ffcf30f30cf30c00ffff0030cf30cf0cf3",
       INIT_05 => X"73733939ccccc7c7e3e333339c9ccecefcc0033ff0030ffc3ff0c00ffcc0033f",
       INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_08 => X"f030300c000f0fcff3f0f000300c0c0ffff00ff30ff0300ff00c0ff0cff00fff",
       INIT_09 => X"f81ffa07fa05fa05a05fa05fe05ff81ff300cff3cff3300ff00ccff3cff300cf",
       INIT_0A => X"ff00abd5ff002addbb5400ffabd500ff4df3df3004ff4df3cfb2ff200cfbcfb2",
       INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
  )
-- synopsys translate_on
  port map(
       ADDR => ADDR,
       CLK => CLK,
       DI(0) => GND,
       DO(0) => dout(0),
       EN => VCC,
       RST => GND,
       WE => GND
  );

U10 : RAMB4_S1
-- synopsys translate_off
  generic map (
       INIT_00 => X"3030cfcfcfcf3030f3f30c0c0c0cf3f33cc33cc30ff00ff0f00ff00f3cc33cc3",
       INIT_01 => X"000000000000000000000000000000007ffcf0c0fcf0c000fffcf0c0fcf0c000",
       INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_04 => X"3cccccc3cfc3c330f330300c3c0c0cc30303ccfc3f33c0c0fcff3303c0cc3f33",
       INIT_05 => X"7ffefeeafefaeaa8eaa8a880a8a0800133cc33cc3cc333c03c333cc3cc33fc33",
       INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_08 => X"ff000000ff0f0f00ff000000ff0f0f00f3cf30f3f3cf00f0f3ff0c3030ff0c30",
       INIT_09 => X"91896e76767789e8e8ee159191896e76fc00ffcc0033ff00ffc033fffc00ffc0",
       INIT_0A => X"d2d64bd2696b2969696b2d69b42d96b4a55a5aada55a5aa55aa5a55a5aa5a55a",
       INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
  )
-- synopsys translate_on
  port map(
       ADDR => ADDR,
       CLK => CLK,
       DI(0) => GND,
       DO(0) => dout(5),
       EN => VCC,
       RST => GND,
       WE => GND
  );

U11 : RAMB4_S1
-- synopsys translate_off
  generic map (
       INIT_00 => X"000ccccc000ccccccccfffffcccfffff33ff33ff33ffffff0033003300333333",
       INIT_01 => X"000000000000000000000000000000007cc3c33cc30f3cf0f8c3873cc31e3ce0",
       INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_04 => X"ccc0c0c3c30303333333333c3f3c3cccc00ff00f0ff0033f03fcf00f0ff00ff0",
       INIT_05 => X"3cc3c33cc30c3cc33cc3c33cc31c3cc3c0f03f030f03f0fc00f03f0f3f0fc0fc",
       INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_08 => X"ff0000f0f00f0f00ff0000f0f00f0f00cfcf0030cc0c30333033cfcff3f3cc0c",
       INIT_09 => X"a779615a1a8786e1791e1a87a779615acf33c330cc33cc33330c33ccc330f33c",
       INIT_0A => X"922664d9d992b66d499b926464d9d9b6999c98c667717119673971998ee6e667",
       INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
  )
-- synopsys translate_on
  port map(
       ADDR => ADDR,
       CLK => CLK,
       DI(0) => GND,
       DO(0) => dout(3),
       EN => VCC,
       RST => GND,
       WE => GND
  );

U12 : RAMB4_S1
-- synopsys translate_off
  generic map (
       INIT_00 => X"0ff3300f0ff000ff0ff000ffff300cff0300fc3fff0300ff03c0ff3fff00c0ff",
       INIT_01 => X"0000000000000000000000000000000073633133cc8cc6cee6c6676698198c98",
       INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_04 => X"f03c3c0f0fc3c3f0c3f0f03f3c0f0ff0c3f3cfc3cfc33cc33c3cf33cf33cc330",
       INIT_05 => X"4fb0f20d3cc3cb34cf30f00f2cd3c33ccff3cccc3ccc3330333cf333cff3cccc",
       INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_08 => X"0f3030ffff0000ff0cf0f0ffcf0000fff0000ffc0fffc00f000ff000f0000ff0",
       INIT_09 => X"a5baa5a25a5f5a5f5a055a05a5faa5bac33c0cc30cc33cccc3300cc30cc33c0c",
       INIT_0A => X"999966b3999966bb6632996666b39966699a96a69669699a9624694969929624",
       INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
  )
-- synopsys translate_on
  port map(
       ADDR => ADDR,
       CLK => CLK,
       DI(0) => GND,
       DO(0) => dout(1),
       EN => VCC,
       RST => GND,
       WE => GND
  );

U2 : RAMB4_S1
-- synopsys translate_off
  generic map (
       INIT_00 => X"ccc00333ccc33333333ccccc33fccccccc33cf33cc333333330c33cc33cc0ccc",
       INIT_01 => X"0000000000000000000000000000000040bf02ff33cc3bccc43b44bb23dd33dc",
       INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_04 => X"000c0c0f0fcfcfff3000000f0c0f0fffcfff303030300ccf0c0cfff3fff33000",
       INIT_05 => X"b0ff00f2f3cf30fb30ff00f0f3df30f3c330c33cf33cf00c0ff3cff0c330c33c",
       INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_08 => X"f0c0c00f0f0f0ff0f000000f0f0f0ff03c3ccc3c33c33c333c333c3cc3c333c3",
       INIT_09 => X"39dcc63b63999c669c666399399cc62303c00f03f0fcc0f0fc3ff0fc0f033f0f",
       INIT_0A => X"4bb4d2bcb44b2d4b2dc24bd2d2bcb42d177a7ea17ee8e8857ea1e817e885815e",
       INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
  )
-- synopsys translate_on
  port map(
       ADDR => ADDR,
       CLK => CLK,
       DI(0) => GND,
       DO(0) => dout(2),
       EN => VCC,
       RST => GND,
       WE => GND
  );

U3 : RAMB4_S1
-- synopsys translate_off
  generic map (
       INIT_00 => X"c3c3c3c3c3c3c3c33c3c3c3c3c3c3c3ccccccccc3333333333333333cccccccc",
       INIT_01 => X"0000000000000000000000000000000070f30c30f3ff30f0f0f30830f3ef30f0",
       INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_04 => X"0ff0f00cf30c0cc33cc3c330cf30300f03c333c33c333c3cc3c033c33c333c33",
       INIT_05 => X"6aa9a995a9a595569556566a564a6aa93000f0f00f0f000c0fff0f0ff0f0cff3",
       INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_08 => X"000000ff000f0fff000000ff000f0fff3cc3c30c3cc3f30f0cf03cc3cf303cc3",
       INIT_09 => X"c69e869c9c191879616763e6c69e869c03ccfc33ff3300cccc3f330003cccc3f",
       INIT_0A => X"b99d22bb44469dd4d446b9dd22bb4462eeefeff7888e8eee88ce8eee00080888",
       INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
  )
-- synopsys translate_on
  port map(
       ADDR => ADDR,
       CLK => CLK,
       DI(0) => GND,
       DO(0) => dout(4),
       EN => VCC,
       RST => GND,
       WE => GND
  );

U4 : RAMB4_S1
-- synopsys translate_off
  generic map (
       INIT_00 => X"ff00ff00ff00ff00ff00ff00ff00ff00ffff0000ffff0000ffff0000ffff0000",
       INIT_01 => X"00000000000000000000000000000000ff00ff00ff00ff00ff00ff00ff00ff00",
       INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_04 => X"ff0c0c00ffcfcf00ff000000ff0f0f00ffff0000ffff0000ffff0000ffff0000",
       INIT_05 => X"ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00",
       INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_08 => X"ff0c0c00ffcfcf00ff000000ff0f0f00ffff0000ffff0000ffff0000ffff0000",
       INIT_09 => X"ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00",
       INIT_0A => X"ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00ff00",
       INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
  )
-- synopsys translate_on
  port map(
       ADDR => ADDR,
       CLK => CLK,
       DI(0) => GND,
       DO(0) => dout(11),
       EN => VCC,
       RST => GND,
       WE => GND
  );

U5 : RAMB4_S1
-- synopsys translate_off
  generic map (
       INIT_00 => X"f00f3fc03fc00ff0f00ffc03fc030ff0f3300ccf0ffff000fff0000f0ccff330",
       INIT_01 => X"00000000000000000000000000000000255a5aa5a55a5aa55aa5a55a5aa5a55a",
       INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_04 => X"30f0f0f30c0c0c3cc3c3c3cf303030f30c0cf0f0cfc30f0f0f0f3c0cf0f0cfc3",
       INIT_05 => X"daa5a55a5aa5a55aa55a5aa5a55a5aa40fc30fc3fc3ff03c03f003c03c0f3c0f",
       INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_08 => X"c33c3c3c3cccccc33cc3c3c3c333333cff3000ff00cfff00ff000cff00fff300",
       INIT_09 => X"dad2b4a45b5ad2b2b2b4a525dad2b4a4f00f0ff0f03c0ff0f00fc3f0f00f0ff0",
       INIT_0A => X"dfdbb0204d4ff2b2b2b00d4dfbf22404f550500af550500aaff5f550aff5f550",
       INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
  )
-- synopsys translate_on
  port map(
       ADDR => ADDR,
       CLK => CLK,
       DI(0) => GND,
       DO(0) => dout(6),
       EN => VCC,
       RST => GND,
       WE => GND
  );

U6 : RAMB4_S1
-- synopsys translate_off
  generic map (
       INIT_00 => X"3fcc003f003fcc033fcc03ff03ffcc03000ff330f00ffff0f0000ff0f3300fff",
       INIT_01 => X"00000000000000000000000000000000b44f4ff2f22c2ccb2ccbcbb0b00d0dd3",
       INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_04 => X"fc3c3c3fc0c0c0f0f0f0f0fc030303c0f0f00000f0fc0000ffffc0f0fffff0fc",
       INIT_05 => X"b0cb0db0d30d34d334d34f34f24f2cf2ff33ff3333003f03ff03ff3333003300",
       INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_08 => X"3ffcfcfcf0c0c0c0fcf0f0f0c0000003000fff00f00ffff0f0000ff0ff000fff",
       INIT_09 => X"3fdcc403bfdcc0033ffcc4023fdcc4033fcc003f03ffcc033fcc003f03ffcc03",
       INIT_0A => X"2ff0f0f0f040f00f0ff0fdf0f0f0f00b344f4ff0f22c2cc33ccbcbb0f00d0dd3",
       INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
  )
-- synopsys translate_on
  port map(
       ADDR => ADDR,
       CLK => CLK,
       DI(0) => GND,
       DO(0) => dout(8),
       EN => VCC,
       RST => GND,
       WE => GND
  );

U7 : RAMB4_S1
-- synopsys translate_off
  generic map (
       INIT_00 => X"0030ffff0000f3ff0030ffff0000f3ff00ff00ff00f000ff00fff0ff00ff00ff",
       INIT_01 => X"0000000000000000000000000000000000ff00ff00ff00ff00ff00ff00ff00ff",
       INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_04 => X"000c0cff00cfcfff000000ff000f0fff00ffffff000000ff00ffffff000000ff",
       INIT_05 => X"00ff00ff20ff00ff00ff00fb00ff00ff00f0f0ff00f0f0ff00f0f0ff00f0f0ff",
       INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_08 => X"000c0cff00cfcfff000000ff000f0fff00ff00ff00f000ff00fff0ff00ff00ff",
       INIT_09 => X"00f330ff00f330ff00f330ff00f330ff0030ffff0000f3ff0030ffff0000f3ff",
       INIT_0A => X"00ff000f0fff00ff00ff000f0fff00ff00ff00ff00ff00ff00ff00ff00ff00ff",
       INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
  )
-- synopsys translate_on
  port map(
       ADDR => ADDR,
       CLK => CLK,
       DI(0) => GND,
       DO(0) => dout(10),
       EN => VCC,
       RST => GND,
       WE => GND
  );

U8 : RAMB4_S1
-- synopsys translate_off
  generic map (
       INIT_00 => X"f0c3f0f0f0f03cf0f0c3f0f0f0f03cf0fff0ffff000f0000ffff0fff0000f000",
       INIT_01 => X"00000000000000000000000000000000fbb0b000fff3f330f3303000fff2f220",
       INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_04 => X"f30c0cf030cfcf00ff0000f3f00f0f30ff0000ff00ffff00ff0000ff00ffff00",
       INIT_05 => X"ff30f200dff2fb20fb20b004ffb0f300f00f0ff0f00f0ff0f00f0ff0f00f0ff0",
       INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_08 => X"f00c0cf300cfcf30f30000ff300f0ff0fff0ffff000f0000ffff0fff0000f000",
       INIT_09 => X"f02ccbf0f02ccff0f00ccbf0f02ccbf0f0c3f0f0f0f03cf0f0c3f0f0f0f03cf0",
       INIT_0A => X"ff0f0ff0f0bf0f00ff0f02f0f00f0f00fbb0b000fff3f330f3303000fff2f220",
       INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
  )
-- synopsys translate_on
  port map(
       ADDR => ADDR,
       CLK => CLK,
       DI(0) => GND,
       DO(0) => dout(9),
       EN => VCC,
       RST => GND,
       WE => GND
  );

U9 : RAMB4_S1
-- synopsys translate_off
  generic map (
       INIT_00 => X"c3cc33f333f3cc3cc3cc30333033cc3cf00ffcc0000ff00f0ff00ffffcc00ff0",
       INIT_01 => X"0000000000000000000000000000000046636339399c9cc69cc6c6636339399c",
       INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_04 => X"0ccccccfc3c3c3f33030303c0c0c0ccf0f0f00000f03f0f0f0f03f0fffff0f03",
       INIT_05 => X"63c639639c39c69cc69c63c639639c39330c330ccf33c330333c330ccf33cf33",
       INIT_06 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_07 => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_08 => X"cf0c0c0cf3c3c3cf0c303030cf0f0f0cf00ff0f00f3ff00f0ff0030ff0f00ff0",
       INIT_09 => X"e31cc738639ce33cc338c639e31cc738c3cc33c33c03cc3cc3cc3fc33c33cc3c",
       INIT_0A => X"df2000ffb24fff00ff000db200fffb04c6636333399c9cccccc6c6633339399c",
       INIT_0B => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0C => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0D => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0E => X"0000000000000000000000000000000000000000000000000000000000000000",
       INIT_0F => X"0000000000000000000000000000000000000000000000000000000000000000"
  )
-- synopsys translate_on
  port map(
       ADDR => ADDR,
       CLK => CLK,
       DI(0) => GND,
       DO(0) => dout(7),
       EN => VCC,
       RST => GND,
       WE => GND
  );


---- Power , ground assignment ----

GND <= GND_CONSTANT;
VCC <= VCC_CONSTANT;

end RAm;

Article: 39732
Subject: Re: Handel-C, System-C, Formal verification ???
From: thomas.stanka@tesat.de (Thomas Stanka)
Date: 18 Feb 2002 07:51:27 GMT
Links: << >>  << T >>  << A >>
Hi,
    	
Phil Hays <spampostmaster@attbi.com.com> wrote:
> The third alternative is formal verification.  I have no experience in
> such tools, so does anyone have experience, opinions (or both) on the
> question of would this help to produce FPGA hardware that matches the
> original C? 

The formal verification tools on market do equivalence checking between 
VHDL, Verilog and similar HDL. What you need is a tool for model checking 
between C and VHDL. I don't think, you might find such a tool. I remember 
that a tool for formal verification of software claims to do so in further 
versions, but don't expext too much in the next years.
Another point is, that equivalence checking do well for designs up to 1M 
gates. Modelchecking usually needs small designparts of a few thousand 
gates.

bye Thomas

-- 
Thomas Stanka TE/EMD4
Space Communications Systems
Tesat Spacecom GmbH & Co KG
thomas.stanka@tesat.de

Article: 39733
Subject: Re: Do I need to install software in order to use Multilinx?
From: ZhengLin <>
Date: Mon, 18 Feb 2002 01:56:32 -0800
Links: << >>  << T >>  << A >>
Just use foundatation 4.1!

Article: 39734
Subject: FPGA: JTAG CABLE
From: "shiva kumar" <shivak210m@yahoo.com>
Date: Mon, 18 Feb 2002 02:43:07 -0800
Links: << >>  << T >>  << A >>
why does the JTAG CABLE not work on Dell systems for programming
vertex FPGA's.

Article: 39735
Subject: Re: FPGA: JTAG CABLE
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Mon, 18 Feb 2002 11:12:04 +0000
Links: << >>  << T >>  << A >>


shiva kumar wrote:

> why does the JTAG CABLE not work on Dell systems for programming
> vertex FPGA's.

More details needed before the collective might of this NG can help you.

How does it "not work" ? What error messages are you getting from
JTAGProgrammer or iMPACT ?

What Xilinx s/w are you using ? Do the rest of the tools work o.k. ?




Article: 39736
Subject: Re: Making Altera development quicker
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 18 Feb 2002 11:45:58 +0000
Links: << >>  << T >>  << A >>
Julian Cox <CoxJAisaspamhater@august-systems.co.uk> writes:

<snip>
> This time I've gone for the xeons A) to avoid P4 (crapomatic) and B)
> the cost of RAID has gone up.  I'd have gone Dual MP1900+ if I could
> have found one.  Quantity of RAM is easy to gauge once to get going,
> just make sure you choose a PC that can take shedloads if it proves
> necessary.
> 

Erm, sorry, but I think the Xeons are P4 core these days as well...
certainly they are NetBurst(TM :-)
http://www.intel.com/eBusiness/products/workstation/midhigh/ds011403.htm

I don't think the old Xeon core could make it to 1.7GHz - I'll be
happy to be corrected though as I'm just pondering what to buy for my
next workstation...

Cheers,
Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Article: 39737
Subject: Altera library problems.
From: "Paul" <nospam@nospamplease.com>
Date: Mon, 18 Feb 2002 12:03:25 -0000
Links: << >>  << T >>  << A >>
I've generated an altclklock using the Altera megafunction wizard and
Quartus 2 1.1 SP2 is happy to synthesise and P&R.

However the same file is not at all happy in Leonardo (2001_1d Altera
edition). Synthesis should create a black box but then P&R back with Quartus
2 doesn't work.

I believe this was working fine last time I tried with a similar P&R, but my
Quartus 2 version has incremented (previously used version probably Q2 1.0
SP2 or 1.1 no SP)


I suspect that the library altera_mf used to be something else???

Can someone with an earlier version of Q2 try generating a simple PLL (I
used a clock 1 @ 133MHz PLL x1 with a 'locked' output but this was an
arbitrary choice) and compare the included library to that below.


Here's an extract from the generated file:

LIBRARY ieee;
USE ieee.std_logic_1164.all;

LIBRARY altera_mf;
USE altera_mf.altera_mf_components.all;

ENTITY plltest IS
 PORT
 (
  inclock  : IN STD_LOGIC ;
  locked  : OUT STD_LOGIC ;
  clock1  : OUT STD_LOGIC
 );
END plltest;


ARCHITECTURE SYN OF plltest IS
<snipped>
END SYN;

---------------------------------------
Not sure that use of altera_mf is the same as before....

Any insights appreciated.

Paul



Article: 39738
Subject: Re: JTAG CABLE
From: "MH" <blahblah@blahblah.blah>
Date: Mon, 18 Feb 2002 13:00:54 -0000
Links: << >>  << T >>  << A >>

"shiva kumar" <shivak210m@yahoo.com> wrote in message news:ee74e9d.-1@WebX.sUN8CHnE...
> why does the JTAG CABLE not work on Dell systems for programming
> vertex FPGA's.


I have seen this problem on a few different PCs, and it
is usually due to incorrect or missing parallel port
driver software. Check out the following records in
the Xilinx database: Answer Record 13360, 11502, 9984.


MH.





Article: 39739
Subject: Re: Pseudorandom Bitstream
From: Stromeko@nexgo.de (Achim Gratz)
Date: 18 Feb 2002 05:08:46 -0800
Links: << >>  << T >>  << A >>
Stromeko@nexgo.de (Achim Gratz) wrote in message news:<73b09d4c.0202080804.4f7a69a0@posting.google.com>...
> [...]

As an addition to the earlier summary for those interested:

As it turned out that you need to have a uniformly distributed stream
of integer numbers, I conducted another search in that direction.
Generally you'll get lots of hits on (software) implementations for
general computers and the tricks required to produce floating point
numbers out of integers and vice versa plus appplications to
cryptography and/or Monte Carlo simulation.

Some of the successful search terms: PRNG QRNG RNG LFSR GFSR
Tausworthe (PRBS parallel)

A site with lots of useful references: http://www.ciphersbyritter.com

In there it is briefly mentioned that you should collect the bits for
your output from equally distributed places in the sequence, which
seems to relate to Ray Andrakas remark that one could use several LFSR
seeded at different places to get a multibit output. I have not found
an efficient way to compute the required seed values for really long
sequences, however.

Notes:

I found a hint in an earlier article in this group on how to
efficiently describe an "unrolled" LFSR that behaves like it is
clocked n times per tick. It involves writing up the original state
machine inside a for...loop in VHDL and collecting the outputs and the
new shift bits in the appropriate registers. If anybody is interested
I can post the code.

There is also an easy way to prevent the synthesis from infering SRL16
on Xilinx if you desire: Ray Andraka mentioned that a RESET will do
the trick, you can also copy the LFSR state to a variable, change that
and assign the changed state back to the LFSR registers. Look Ma,
everything done with FF now ...


Achim.

Article: 39740
Subject: Timing constraints
From: dorron@hotmail.com (Paul)
Date: 18 Feb 2002 06:15:50 -0800
Links: << >>  << T >>  << A >>
Hy!!!

I'm developing some design in a Xiling VirtexE 100, until now
everything used to work O.K., but since the design is becomming bigger
(now i'm using something like 90 % of the slices) I am having some
problems with the place & route tool. Things that already worked stop
working. With the same synthesis result and diferent PAR strategies
sometimes I get it to work. It is very strange that higher effort not
always means better results. Sometimes it worked with medium effort
PAR and failed by highest effort :-( !?!?

Now I know which signal is failing, but I can not constraint it
because it is an internal path (not an I/O pin) and I dont know what
is the name of this signal after Synthesis so I can not constrain it.
Could someone help me? 

Thanks in advance,
Paul.

Article: 39741
Subject: Re: Power estimation for Virtex-2 device
From: Nate Goldshlag <nateg@pobox.com>
Date: Mon, 18 Feb 2002 09:21:31 -0500
Links: << >>  << T >>  << A >>
In article <3C698A22.D81224EE@andraka.com>, Ray Andraka <ray@andraka.com> 
wrote:

> There is a tool in the 4.1 tools called xpower that will take the VCD
> file from your simulation and the NCD from the place and route to
> provide a more accurate power computation based on your simulation.
> 

However, that xpower works like crap.  I made a .vcd file with only 100 clock 
cycles of a Virtex-E XCV200 design that is only about 1/2 full.  The .vcd file 
was only 8 megabytes and xpower hung reading it in.  I let it run overnight 
and when I came in in the morning the thing had crashed.

Not ready for prime time.

Nate

----------------------------------------------------
Nate Goldshlag      nateg@pobox.com
Arlington, MA       http://www.pobox.com/~nateg

Article: 39742
Subject: Re: Power estimation for Virtex-2 device
From: Phil Hays <spampostmaster@attbi.com.com>
Date: Mon, 18 Feb 2002 14:42:46 GMT
Links: << >>  << T >>  << A >>
Nate Goldshlag wrote:
 
> In article <3C698A22.D81224EE@andraka.com>, Ray Andraka <ray@andraka.com>
> wrote:
> 
> > There is a tool in the 4.1 tools called xpower that will take the VCD
> > file from your simulation and the NCD from the place and route to
> > provide a more accurate power computation based on your simulation.
> >
> 
> However, that xpower works like crap.  I made a .vcd file with only 100 clock
> cycles of a Virtex-E XCV200 design that is only about 1/2 full.  The .vcd file
> was only 8 megabytes and xpower hung reading it in.  I let it run overnight
> and when I came in in the morning the thing had crashed.

You might try it in batch mode.  GUI is buggy.


-- 
Phil Hays

Article: 39743
Subject: Book Recommendation for Designing Complex System using HDL.
From: antipattern@hotmail.com (Unit Manager)
Date: 18 Feb 2002 08:06:51 -0800
Links: << >>  << T >>  << A >>
Hi Group,

I already had some working knowledge of VHDL and Verilog but I would
like to get a book or some to guide me for (1) doing design for
complex systems AND
(2) picking up techniques to clear the dirty corners of HDL design
such as async behaviour, signal crossing clock domains, verification,
etc that are slightly or even not mentioned in most HDL intro books.

I aware of two books for my next digital logic design reading. I would
like to get some review from experienced readers for recommendations:

1. "Real Chip Design and Verification Using Verilog and VHDL"
VhdlCohen Publishing, ISBN  0-9705394-2-8
2. "VHDL Coding and Logic Synthesis with Synopsys" by Weng Fook Lee

Thanks,

-pat.

Article: 39744
Subject: Re: JTAG CABLE
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Mon, 18 Feb 2002 16:54:12 +0000
Links: << >>  << T >>  << A >>


MH wrote:

> "shiva kumar" <shivak210m@yahoo.com> wrote in message news:ee74e9d.-1@WebX.sUN8CHnE...
> > why does the JTAG CABLE not work on Dell systems for programming
> > vertex FPGA's.
>
> I have seen this problem on a few different PCs, and it
> is usually due to incorrect or missing parallel port
> driver software. Check out the following records in
> the Xilinx database: Answer Record 13360, 11502, 9984.
>
> MH.

There is another circumstance beyond #13360 that might cause the PP driver to get lost. I
usually maintain the current Foundation/ISE version, its predecessor, and the most recent
webPACK. If I install a new set of s/w and then uninstall an old one the PP driver gets
removed during the uninstall. I've also come across the case of another piece of PC s/w
that one of our s/w engineers installed on my machine (He didn't have a Win PC, only a
Linux box) that had its own PP driver and installed it in the same place as Xilinx
installs theirs!

Note:. The solution record #9984 is less helpful than it might be since a condition of the
Jungo license is that Xilinx may not distribute the WinDrvr.h header file so users of
Xilinx s/w cannot write independent code that accesses the WinDrvr PP driver.


Article: 39745
Subject: Re: Book Recommendation for Designing Complex System using HDL.
From: "Srinivasan Venkataramanan" <srinivasan@siliconsystems.no_spam.co.in>
Date: Mon, 18 Feb 2002 22:41:12 +0530
Links: << >>  << T >>  << A >>
Hi,
  As I am currently reading through the book:
Real Chip Design - by Ben - I would highly recommend it for people with
medium skills in any of the HDLs. I will try and post a comprehensive review
once I finish reading it. But surely this book does address all the issues
that you have asked for, in great detail.

Good Luck,
Srinivasan

"Unit Manager" <antipattern@hotmail.com> wrote in message
news:e1f38cc5.0202180806.3891e2fb@posting.google.com...
> Hi Group,
>
> I already had some working knowledge of VHDL and Verilog but I would
> like to get a book or some to guide me for (1) doing design for
> complex systems AND
> (2) picking up techniques to clear the dirty corners of HDL design
> such as async behaviour, signal crossing clock domains, verification,
> etc that are slightly or even not mentioned in most HDL intro books.
>
> I aware of two books for my next digital logic design reading. I would
> like to get some review from experienced readers for recommendations:
>
> 1. "Real Chip Design and Verification Using Verilog and VHDL"
> VhdlCohen Publishing, ISBN  0-9705394-2-8
> 2. "VHDL Coding and Logic Synthesis with Synopsys" by Weng Fook Lee
>
> Thanks,
>
> -pat.



Article: 39746
Subject: Re: FPGA: JTAG CABLE
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Mon, 18 Feb 2002 09:46:41 -0800
Links: << >>  << T >>  << A >>

Hi Shiva,

I have encountered problems using Dell systems with parallel
download cables when used with the Hardware Debugger.  I don't
know if this applies to the JTAG Programmer software or not.
Actually, I don't even think it is specific to Dell machines;
there have been a number of threads on comp.arch.fpga on this
topic.

I teach a class at San Jose State, and the entire lab is filled
with Dell machines.  It seems (by luck of the draw) that some
machines will not configure an FPGA correctly.

The symptoms?  The Hardware Debugger will attempt to configure,
and then indicate it was successful.  However, the FPGA appears
to be "dead".

I traced it down to some glitches on the port signals; what
happens is that the FPGA is actually configured, and then
"accidentally" cleared at the end of the programming sequence.
My workaround was to cut traces on the board so that the FPGA
cannot be initialized after the first power-on configuration.
Now it always configures the first time, but the downside to
the workaround is that if you want to configure again, you
must cycle the power to the board.

Hope that helps,
Eric

shiva kumar wrote:
> 
> why does the JTAG CABLE not work on Dell systems for programming
> vertex FPGA's.

Article: 39747
Subject: Xilinx IP Core multiplier performance
From: Przemyslaw Wegrzyn <czajnik@czajsoft.pl>
Date: Mon, 18 Feb 2002 19:29:19 +0100
Links: << >>  << T >>  << A >>

Hello !

I need to implement signed 16x16 bit multiplier in my graduate project, I'm 
going to use Spartan-II device. 

The question is:
Are the multipliers generated by Xilinx's Multiplier Generator v4.0 IP well 
optimized ?
Can I gain any better performance/resource utilisation building a 
multiplier block myself (at reasonable effort) ? 

P.Wegrzyn


Article: 39748
Subject: Re: Do I need to install software in order to use Multilinx?
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Mon, 18 Feb 2002 19:50:35 +0100
Links: << >>  << T >>  << A >>
<ZhengLin> schrieb im Newsbeitrag news:ee74e92.0@WebX.sUN8CHnE...
> Just use foundatation 4.1!

NO, just install the JTAG-Programmer from Webpack, it will automaticall
install the parallel cable driver.

--
MfG
Falk





Article: 39749
Subject: Re: Edge selection with RAM
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Mon, 18 Feb 2002 19:54:22 +0100
Links: << >>  << T >>  << A >>
"Antonio" <dottavio@ised.it> schrieb im Newsbeitrag
news:fb35ea96.0202172343.7ae21d4b@posting.google.com...

> # : WARNING: */RAMB4_S1 SETUP High VIOLATION ON ADDR(8) WITH RESPECT
> TO CLK;
> # :   Expected := 0.01 ns; Observed := 0 ns; At : 1275 ns
> # : Time: 1275 ns,  Iteration: 3,  Instance: /U1/U2/U2/B13.
> # : WARNING: */RAMB4_S1 SETUP Low VIOLATION ON ADDR(7) WITH RESPECT TO
> CLK;
> # :   Expected := 0.01 ns; Observed := 0 ns; At : 1275 ns
> # : Time: 1275 ns,  Iteration: 3,  Instance: /U1/U2/U2/B13.

I think this problem has been discussed recently, its a bug in the
simulation model of the RAM.

> and really many other similar warnings, but let's try to understand
> what the error say,
> the problem is that the clock and the address change on the same time
> while from data_sheets
> seems that the address must arrive a little bit before 0.01ns.

Yes, a "little" bit more, so 2ns or so. ;-)

>
> The only rimedy I know is to change the operating edge of the ram so
> now the address change on
> negative edge of the clock and the ram work on positive edge. Now the
> simulation it's ok but
> the speed on FPGA is reduced to 45MHz.

This is clear, since the address changes on the negative edge and has so
only 1/2 clock cycle to propaget to the RAM. Switch back to te positive edge
and ignore the warning of the simulator. If you have a clean synchronous
design, just look at the timing analyzer, it will tell you how fast you can
go.

--
MfG
Falk







Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search