Messages from 35575

Article: 35575
Subject: Re: Synplicity/Leonardo License Agreement Information
From: "Jeff Cunningham" <jcc@sover.net>
Date: Wed, 10 Oct 2001 22:46:03 -0400
Links: << >> << T >> << A >>


Austin Franklin <austin@dar87kroom.com> wrote in message
news:ts7f3mcvi2r3e5@corp.supernews.com...
> I know this is "controversial" but this kind of crap just really "irks"
> me...

Indeed.

If I recall correctly, I saw something like this when installing the xilinx
free tools - was it the XST synthesis tool; or maybe it was the free version
of ModelSim? Though what I remember is that the prohibition was on
"publishing" any benchmark results, as in posting to usenet; I can't see how
emailing results to one person would even be in violation of that assinine
license clause.

Jeff

Article: 35576
Subject: Re: Virtex-2 maximum clock speed
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Thu, 11 Oct 2001 05:16:20 -0000
Links: << >> << T >> << A >>

> Hand placement leads to wonderful performance, but it leads to
> unmaintainable designs.

That doesn't match my experience.  I'm typically working on
designs that run at bleeding-edge speeds.  I'm willing to
limit my design complexity to something that I'm willing to
hand route.

Several years ago, I was working on a 3090 design.  The data
path was hand placed.  (That's a no brainer.)  I had most
of the control logic hand placed.  I tried to get the tools
to do the rest.  It took a long time to not get good results.
I found that I could do several iterations of hand placement
and trial routing faster than the system could do the automagic
placement and routing.

Six months ago I was working on a VirtexE.  I had a simple
design with many LFSRs.  Getting out of the SRL16s was the
slow part.  I had lots of pipeline FFs to make the rest
of things easy for the tools.  The tools were not smart
enough to place the SRL16s near the logic that needed it.
(I may have the details wrong but that's the general idea.)

I could do the placement by hand in a half hour or so.  How
long would it have taken me to find a "clean" way to do the job?



> One really neat feature is the variable phase shift, which one uses to
> verify the eye opening!  Oops, I'm sorry, that sounded like marketing....but
> I plead that it is still a really neat engineering feature to verify the eye
> opening without having to buy a $$$$$$$ instrument.

Neat suggestion.  Thanks.

Note that not only do you avoid the expensive test gear in the lab,
but you get to ship the appropriate tool to each customer so you can
retest things in the field.  Might be handy if there are external
cables or strange temperatures.  (or you just need a sanity check)

-- 
These are my opinions, not necessarily my employeers.  I hate spam.

Article: 35577
Subject: Re: 155MHz to DLL in Spartan II
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Thu, 11 Oct 2001 06:37:28 -0000
Links: << >> << T >> << A >>

> As I understand it, the problem is how to interface values that
> are computed using the 155 MHz Clock to logic running at the PCI
> Clock that is asynchronous to the fast clock.

> There are some metastability wizards in this newsgroup that
> propably can better explain the possible solutions than I can.

Reading a counter running off one clock from another clock
is hard/tricky, but you can easily get in trouble without
any metastability.

Consider when the counter is changing from 000fff to 001000.
Suppose it changes just as you are reading it.  The clock-out,
prop, and setup times on the different bits will be slightly
different.  So the 1 might get there before some of the bits
in the fff part change to 0s.  That gives you a wrong answer.

It's a valid number but it won't make sense if you compare it
to other readings taken before or after.  That is you might get
a sequence of readings like this:
   000e00
   000f00
   001100  (should be 000fff or 001000)
   001100
   001200


You could cound in gray code.  Not very FPGA friendly.


If "all" you want is a counter that's driven by the 155 MHz clock
so you can do something like feed it into your NTP server to have
a reference that is much more stable than your CPU clock, then I would
do something like this:

  Use the 155 MHz signal to clock a small counter.
   Ripple counter OK here.
  Pick a bit on that counter that is slower
   than half your PCI clock.
  Run that bit through a synchronizer to get
   a good/clean signal on the PCI clock domain.
  Because it is slower than half/clock you will
   see the high half and each low half of each cycle.
  Make a small FSM that emits a 1 cycle pulse on
   each state change.
  Use that pulse to gate a counter.
   That's the counter you want to read.

Others have already mentioned many of those ideas.  Note that
there is no need for a DLL running at 155 MHz.  (You may need
one for other reasons, but it isn't needed here.)

-- 
These are my opinions, not necessarily my employeers.  I hate spam.

Article: 35578
Subject: Re: Linking components in VHDL
From: "Andrew Gray" <andrew@tuks.co.za>
Date: Thu, 11 Oct 2001 09:20:06 +0200
Links: << >> << T >> << A >>

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01C15235.EAB59E80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Here is my code:



-------------------------------------------------------------------------=
-------
-- Specify Libraries.
-------------------------------------------------------------------------=
-------
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use IEEE.std_logic_unsigned.all;
use IEEE.std_logic_signed.all;


-------------------------------------------------------------------------=
-------
-- Define Entity.
-------------------------------------------------------------------------=
-------
entity audio_data2 is
  port (
   =20
 =
-------------------------------------------------------------------------=
---
 -- Inputs and Outputs
 =
-------------------------------------------------------------------------=
---
 CLK_64MHz     : in std_logic; -- clock 64MHz
 Data_train    : in std_logic;
 Data_ready    : in std_logic;
 mode          : in std_logic_vector(1 downto 0);
 T_alloc_out   : out std_logic_vector(3 downto 0));
=20
end audio_data2;=20


-------------------------------------------------------------------------=
-------
-- Define Architecture.
-------------------------------------------------------------------------=
-------
architecture read of audio_data2 is


component alloc_shift
 PORT
 (
  clock    : IN STD_LOGIC ;
  shiftin  : IN STD_LOGIC ;
  aclr     : IN STD_LOGIC ;
  q        : OUT STD_LOGIC_VECTOR (3 DOWNTO 0)
 );
end component;



-------------------------------------------------------------------------=
-------
-- Constants
-------------------------------------------------------------------------=
-------

-------------------------------------------------------------------------=
-------
-- Types
-------------------------------------------------------------------------=
-------
type allocation  is array (31 downto 0) of std_logic_vector(3 downto 0); =
=20
type scalefactor is array (31 downto 0) of std_logic_vector(5 downto 0);
type sample       is array (31 downto 0) of std_logic_vector(15 downto =
0);

-------------------------------------------------------------------------=
-------
-- Signals
-------------------------------------------------------------------------=
-------
signal allocation_ch0  : allocation;
signal scalefactor_ch0  : scalefactor;
signal temp_sample : sample;
signal sample_0_ch0 : sample;
signal sample_1_ch0 : sample;
signal sample_2_ch0 : sample;
signal sample_3_ch0 : sample;
signal sample_4_ch0 : sample;
signal sample_5_ch0 : sample;
signal sample_6_ch0 : sample;
signal sample_7_ch0 : sample;
signal sample_8_ch0 : sample;
signal sample_9_ch0 : sample;
signal sample_10_ch0 : sample;
signal sample_11_ch0 : sample;

signal data  : std_logic;

signal alloc_buff : std_logic_vector(3 downto 0);
signal clr_alloc_shift  : std_logic;

-------------------------------------------------------------------------=
-------
-- Begin Architecture.
-------------------------------------------------------------------------=
-------
begin


-------------------------------------------------------------------------=
-------
-- Binding of arithmetic block ports.
-------------------------------------------------------------------------=
-------

bind_alloc_shift: alloc_shift
 port map(
  clock     =3D> CLK_64MHz,
  shiftin   =3D> Data_train,
  aclr      =3D> clr_alloc_shift,
  q         =3D> alloc_buff);




Get_data: process(CLK_64MHz)

variable alloc_sb  : integer range 0 to 31 :=3D 0;
variable count_4  : integer range 0 to 3 :=3D 0;

begin -- process Get_data


if (CLK_64MHz'EVENT and CLK_64MHz =3D '1') then -- rising edge

 if (mode =3D "11") then -- single channel

  if (count_4 =3D 3) then -- load allocation subband register

       allocation_ch0(alloc_sb) <=3D alloc_buff;
       T_alloc_out <=3D alloc_buff; -- temp for testing purposes
       alloc_sb :=3D alloc_sb + 1;
  end if; -- load=20

  count_4 :=3D count_4 + 1;
 end if; -- single channel
end if; -- rising edge


end process Get_data;

clr_alloc_shift <=3D '1';

end read;=20


Thanks

Andrew

"Mike Treseler" <mike.treseler@flukenetworks.com> wrote in message =
news:3BC47570.F92EE69F@flukenetworks.com...
> Andrew Gray wrote:
>=20
> > When I compile the project Maxplus generates the error:
> > Warning: Ignored unneccessary INPUT pin 'Data_Train'
> >=20
>=20
> Sounds like there is a missing signal=20
> declaration and/or assignment.
> Post your code.
>=20
> Consider using simulation before synthesis.
>=20
>     --Mike Treseler

------=_NextPart_000_000A_01C15235.EAB59E80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.100" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>Here is my code:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT><BR><FONT face=3DCourier=20
size=3D2>----------------------------------------------------------------=
----------------<BR>--=20
Specify=20
Libraries.<BR>-----------------------------------------------------------=
---------------------<BR>library=20
IEEE;<BR>use IEEE.std_logic_1164.all;<BR>use =
IEEE.std_logic_arith.all;<BR>use=20
IEEE.std_logic_unsigned.all;<BR>use =
IEEE.std_logic_signed.all;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT><BR><FONT face=3DCourier=20
size=3D2>----------------------------------------------------------------=
----------------<BR>--=20
Define=20
Entity.<BR>--------------------------------------------------------------=
------------------<BR>entity=20
audio_data2 is<BR>&nbsp; port (<BR>&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;---------------------------------------------------------------=
-------------<BR>&nbsp;--=20
Inputs and=20
Outputs<BR>&nbsp;--------------------------------------------------------=
--------------------<BR>&nbsp;CLK_64MHz&nbsp;&nbsp;&nbsp;&nbsp;=20
: in std_logic; -- clock 64MHz<BR>&nbsp;Data_train&nbsp;&nbsp;&nbsp; : =
in=20
std_logic;<BR>&nbsp;Data_ready&nbsp;&nbsp;&nbsp;&nbsp;: in=20
std_logic;<BR>&nbsp;mode&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp; : in=20
std_logic_vector(1 downto 0);<BR>&nbsp;T_alloc_out&nbsp;&nbsp;&nbsp;: =
out=20
std_logic_vector(3 downto 0));<BR>&nbsp;<BR>end audio_data2; =
</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><BR><FONT=20
face=3DCourier=20
size=3D2>----------------------------------------------------------------=
----------------<BR>--=20
Define=20
Architecture.<BR>--------------------------------------------------------=
------------------------<BR>architecture=20
read of audio_data2 is</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><BR><FONT=20
face=3DCourier size=3D2>component=20
alloc_shift<BR>&nbsp;PORT<BR>&nbsp;(<BR>&nbsp;&nbsp;clock&nbsp;&nbsp;&nbs=
p;&nbsp;:=20
IN STD_LOGIC ;<BR>&nbsp;&nbsp;shiftin&nbsp;&nbsp;: IN STD_LOGIC=20
;<BR>&nbsp;&nbsp;aclr&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: IN STD_LOGIC=20
;<BR>&nbsp;&nbsp;q&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: OUT=20
STD_LOGIC_VECTOR (3 DOWNTO 0)<BR>&nbsp;);<BR>end component;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier=20
size=3D2>----------------------------------------------------------------=
----------------<BR>--=20
Constants<BR>------------------------------------------------------------=
--------------------</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier=20
size=3D2>----------------------------------------------------------------=
----------------<BR>--=20
Types<BR>----------------------------------------------------------------=
----------------<BR>type=20
allocation&nbsp;&nbsp;is array (31 downto 0) of std_logic_vector(3 =
downto=20
0);&nbsp; <BR>type scalefactor&nbsp;is array (31 downto 0) of =
std_logic_vector(5=20
downto 0);<BR>type sample&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;is array =
(31=20
downto 0) of std_logic_vector(15 downto 0);</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier=20
size=3D2>----------------------------------------------------------------=
----------------<BR>--=20
Signals<BR>--------------------------------------------------------------=
------------------<BR>signal=20
allocation_ch0 &nbsp;: allocation;<BR>signal scalefactor_ch0&nbsp; :=20
scalefactor;<BR>signal temp_sample&nbsp;: sample;<BR>signal =
sample_0_ch0&nbsp;:=20
sample;<BR>signal sample_1_ch0&nbsp;: sample;<BR>signal =
sample_2_ch0&nbsp;:=20
sample;<BR>signal sample_3_ch0&nbsp;: sample;<BR>signal =
sample_4_ch0&nbsp;:=20
sample;<BR>signal sample_5_ch0&nbsp;: sample;<BR>signal =
sample_6_ch0&nbsp;:=20
sample;<BR>signal sample_7_ch0&nbsp;: sample;<BR>signal =
sample_8_ch0&nbsp;:=20
sample;<BR>signal sample_9_ch0&nbsp;: sample;<BR>signal =
sample_10_ch0&nbsp;:=20
sample;<BR>signal sample_11_ch0&nbsp;: sample;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>signal data&nbsp;&nbsp;: =
std_logic;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>signal alloc_buff&nbsp;: =
std_logic_vector(3=20
downto 0);<BR>signal clr_alloc_shift &nbsp;: std_logic;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier=20
size=3D2>----------------------------------------------------------------=
----------------<BR>--=20
Begin=20
Architecture.<BR>--------------------------------------------------------=
------------------------<BR>begin</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><BR><FONT=20
face=3DCourier=20
size=3D2>----------------------------------------------------------------=
----------------<BR>--=20
Binding of arithmetic block=20
ports.<BR>---------------------------------------------------------------=
-----------------</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>bind_alloc_shift: =
alloc_shift<BR>&nbsp;port=20
map(<BR>&nbsp;&nbsp;clock&nbsp;&nbsp;&nbsp;&nbsp; =3D&gt;=20
CLK_64MHz,<BR>&nbsp;&nbsp;shiftin&nbsp;&nbsp;&nbsp;=3D&gt;=20
Data_train,<BR>&nbsp;&nbsp;aclr&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D&gt;=20
clr_alloc_shift,<BR>&nbsp;&nbsp;q&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=3D&gt;=20
alloc_buff);</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><BR><FONT face=3DCourier=20
size=3D2>Get_data: process(CLK_64MHz)</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>variable alloc_sb &nbsp;: integer =
range 0 to 31=20
:=3D 0;<BR>variable count_4 &nbsp;: integer range 0 to 3 :=3D =
0;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>begin -- process =
Get_data</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><BR><FONT=20
face=3DCourier size=3D2>if (CLK_64MHz'EVENT and CLK_64MHz =3D '1') then =
-- rising=20
edge</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;if (mode =3D "11") then -- =
single=20
channel</FONT></DIV><FONT face=3DCourier size=3D2>
<DIV><FONT face=3DArial></FONT><FONT face=3DArial></FONT><FONT=20
face=3DArial></FONT><BR>&nbsp;&nbsp;if (count_4 =3D 3) then -- load =
allocation=20
subband register</DIV>
<DIV><FONT face=3DArial></FONT><FONT face=3DArial></FONT><FONT=20
face=3DArial></FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
allocation_ch0(alloc_sb) &lt;=3D=20
alloc_buff;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; T_alloc_out &lt;=3D=20
alloc_buff; -- temp for testing =
purposes<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
alloc_sb :=3D alloc_sb + 1;<BR>&nbsp;&nbsp;end if; -- =
load&nbsp;</DIV><FONT=20
face=3DArial></FONT><FONT face=3DArial></FONT><FONT =
face=3DArial></FONT><FONT=20
face=3DArial></FONT><FONT face=3DArial></FONT>
<DIV><FONT face=3DArial></FONT><BR>&nbsp;&nbsp;count_4 :=3D count_4 +=20
1;<BR>&nbsp;end if; -- single channel<BR>end if; -- rising =
edge</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><BR><FONT face=3DCourier=20
size=3D2>end process Get_data;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>clr_alloc_shift &lt;=3D =
'1';<BR></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>end read; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Andrew</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>"Mike Treseler" &lt;</FONT><A=20
href=3D"mailto:mike.treseler@flukenetworks.com"><FONT face=3DArial=20
size=3D2>mike.treseler@flukenetworks.com</FONT></A><FONT face=3DArial =
size=3D2>&gt;=20
wrote in message </FONT><A =
href=3D"news:3BC47570.F92EE69F@flukenetworks.com"><FONT=20
face=3DArial =
size=3D2>news:3BC47570.F92EE69F@flukenetworks.com</FONT></A><FONT=20
face=3DArial size=3D2>...</FONT></DIV><FONT face=3DArial size=3D2>&gt; =
Andrew Gray=20
wrote:<BR>&gt; <BR>&gt; &gt; When I compile the project Maxplus =
generates the=20
error:<BR>&gt; &gt; Warning: Ignored unneccessary INPUT pin =
'Data_Train'<BR>&gt;=20
&gt; <BR>&gt; <BR>&gt; Sounds like there is a missing signal <BR>&gt;=20
declaration and/or assignment.<BR>&gt; Post your code.<BR>&gt; <BR>&gt; =
Consider=20
using simulation before synthesis.<BR>&gt; <BR>&gt; &nbsp;&nbsp;&nbsp; =
--Mike=20
Treseler</FONT></BODY></HTML>

------=_NextPart_000_000A_01C15235.EAB59E80--

Article: 35579
Subject: Re: FPGA reset
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Thu, 11 Oct 2001 07:34:37 -0000
Links: << >> << T >> << A >>


>Just a note on using GSR-not using GSR with synthesis.  GSR routing is free,
>it is dedicated copper...and can be used for nothing else.  If you do NOT
>use GSR, and have a reset in your design (as you probably should) you are
>using regular routing resources for this possibly very prolific global net.
>In order for synthesis to use GSR (at least Synplicity) EVERY flop must be
>attached to GSR, or it will use regular routing resources.

Thanks for the reminder.


How come all the pictures in the Xilinx data sheets telling us
where the muxes are and which signals go where don't show the GSR
signal?  (Am I just missing it?)

Is GSR a not-shown input to some mux or is there an extra GSR
input on the FF that's not shown?  Does GSR get ORed with the
set/reset the picture shows?  If I trick the tools into using
the GSR signal, am I wasting the normal set/reset logic?  (Or
are the tools smart enough to use them too, if the hardware
supports that?)

-- 
These are my opinions, not necessarily my employeers.  I hate spam.

Article: 35580
Subject: Re: 155MHz to DLL in Spartan II
From: "Ulises Hernandez" <ulisesh@ecs-telecom.removeplease.co.uk.invalid>
Date: Thu, 11 Oct 2001 08:48:14 +0100
Links: << >> << T >> << A >>

Hello,

Thank you for your answers.

I see that the less recommended solution is using the DLL. As Ray says I
might have trouble getting a 155MHz board level clock into the cheap
clearly.
With all these ideas there is no point to use an external divider if it can
be done in VHDL.
All the solutions are fine, this is a "free" running counter started and
stopped (rarely) by f/w, so I guess Hal and Ray solutions are probably the
most adecuated. Maybe I misunderstood something but in Falk and Peter
solutions you have to stop the counter every gate pulse and read the count
after i.e. 16 cycles.

Thank you all.

Ulises Hernandez
ECS Technology

"Ulises Hernandez" <ulisesh@ecs-telecom.removeplease.co.uk.invalid> wrote in
message news:1002729750.5264.0.nnrp-08.c2de5a16@news.demon.co.uk...
> Hello,
>
> I am using a Spartan II XC2S200-FG256-5. I have a 33.33MHz PCI clock which
I
> can use, I have to count an external recovered clock of 155MHz in a 32 bit
> counter and set the result in a register and when software requires the
> value can read it.
>
> I would like to connect the 155 MHz clock to an IBUFG and then to a DLL
> (CLKDLLHF), divide it by 16 into the DLL and obtain a 9.68 MHz clock which
I
> can read with my 33.33 MHz clock.
> The other possibility is avoiding this "high" frequency using an external
> divider by 4 i.e. and get a 38.75 clock to a DLL (CLKDLL) and divide by 2
> i.e.
>
> Any suggestions? In the Spartan II Datasheets the maximum frequency for a
> CLKDLLHF is 180 MHz. Is it too close? My previous experience with Spartan
II
> DLL is quite good so I trust it, but I would like if someone could give
some
> idea.
>
> Thank you in advance.
>
> Ulises Hernandez
> ECS Technology
>
>
>
>

Article: 35581
Subject: Re: High level synthesis will never work well :)
From: "Andrew Brown" <andrewbr@nortelnetworks.com>
Date: Thu, 11 Oct 2001 09:06:48 +0100
Links: << >> << T >> << A >>

This is the sort of case that should be fed directly to synplicity to allow
them to improve their tools.  If we don't tell them about it how can they
fix it!

A.


"Rick Filipkiewicz" <rick@algor.co.uk> wrote in message
news:3BC4C920.7BB7FA99@algor.co.uk...
>
>
> Don Husby wrote:
>
> > More wacky synthesis results from Synplicity:
> >   module Cnt56(K, CE, R, Out);
> >     input         K, CE, R;
> >     output [55:0] Out;
> >     reg    [55:0] Q;
> >     assign Out= Q;
> >     always @(posedge K) Q <= R ? 0 : CE ? Q+1 : Q;
> >     // if (R)       Q <= 0;    // This doesn't work either
> >     // else if (CE) Q <= Q+1;
> >   endmodule
> On the specific point you are right in that Synplify doesn't appear to
> be using resources efficiently in this case. Esp

Article: 35582
Subject: Dual Port Fifo for Virtex II
From: "Philippe Robert" <PhilippeR@sundance.com>
Date: Thu, 11 Oct 2001 09:36:02 +0100
Links: << >> << T >> << A >>

Hi there,

I have been working on a vhdl design for a Virtex II for a little while now
and I would need to implement Dual Port Fifo. Does anyone have such a block,
or where I could get one ?

Rgds.
Philippe.

Article: 35583
Subject: Timing constraints for unrelated clocks?
From: Leo Breuss <lbreuss-nospam@scs.ch>
Date: Thu, 11 Oct 2001 10:40:04 +0200
Links: << >> << T >> << A >>

I'm using Xilinx ISE 4.1i SP1
How do I specify timing constraints for the following design?
(I did RTFM, but could not completely understand how to apply it
correctly)

The path from Reg1_Out to Reg3_In shall not generate an error in the
timing report for case 1 and/or case 2 (see below). But PAR should still
try to satisfy the timing constraint from Reg2(Clk2) to Reg3(Clk2),
which is 8ns, and optimize all delays (also the delay from Reg1_Out to
MUX_Sel).

          +----+                                                 
          |Reg1|                                                 
    In1   |    |   (delay ~2.0 ns)                               
   o--/---|    |--/-----------------+                            
      5   |    |  5                 |                            
          | /\ |                    |                            
          +----+                    |                            
            |                       |                            
            |                       |                            
           Clk1                     |MUX_Sel                     
                                  |\|                            
          +----+                  | \                    +----+  
          |Reg2|                  |  \                   |Reg3|  
    In2   |    |  (delay ~2.0 ns) |   |  (delay ~1.5 ns) |    |  
   o--/---|    |--/---------------|   |--/---------------|    |--
      32  |    |  32              |   |  1               |    |  
          | /\ |                  |  /                   | /\ |  
          +----+                  | /                    +----+  
            |                     |/                       |     
            |                     MUX 32-to-1              |     
           Clk2                  (TInOut 2.0 ns)          Clk2

case 1:
  Clk2 = not Clk1, period(Clk1) = 8 ns, 50% duty
case 2:
  Clk2 unrelated to Clk1, period(Clk1) = 8ns, period(Clk2) = 6 ns

Many thanks for working tips and any hint.
Leo Breuss

--------------------------------------------------------------------
Leo Breuss                       Email: lbreuss-nospam@scs.ch
Supercomputing Systems AG        Phone: +41 1 445 16 09
Technoparkstr. 1                 Fax:   +41 1 445 16 10
CH-8005 Zürich, Switzerland      Web:   http://www.scs.ch/

Article: 35584
Subject: Error : Operand divide
From: thao <songlam@hn.vnn.vn>
Date: Thu, 11 Oct 2001 01:54:41 -0700
Links: << >> << T >> << A >>

Hi All,

I'm using Virilog based on Foundation ISE 3.1i from Xilinx. I have problem with the divide operand as FPGA Express can not accept variable divide (i.e. f= a/b b can not be variable) but only constant. Is there any body met this problem and can help me to solve it so that the number of occupied gates by the divide operand is minimum.

Thao

Article: 35585
Subject: vhdl code keyboard controller
From: "Rini.van.Dijk" <Rini_van_Dijk@hotmail.com>
Date: Thu, 11 Oct 2001 10:54:50 +0200
Links: << >> << T >> << A >>

Hi all,

-->> second try

I'm working on an fpga project which should include a 'the keyboard
part' of the good old 8279 keyboard/display controller. The design
should be sw-compatible to the keyboard part. So the question is : Is
there anybody out there who has the vhdl-code available for this device,
other then a costly IP-core.

Kind regards,

Please reply to Rini_van_Dijk@hotmail.com

Article: 35586
Subject: Re: Timing constraints for unrelated clocks?
From: "fred" <x@y.z>
Date: Thu, 11 Oct 2001 10:13:37 +0100
Links: << >> << T >> << A >>

Leo Breuss <lbreuss-nospam@scs.ch> wrote in message
news:3BC55AE4.424DF7CC@scs.ch...
> How do I specify timing constraints for the following design?
[circuit snipped]

Hi Leo,

My approach for this would be:

# group clock nets
NET clk_1 TNM_NET = clk_1_grp;
NET clk_2 TNM_NET = clk_2_grp;
# spec single clock domains
TIMESPEC TS_clk_1 = PERIOD : clk_1_grp : 8 ns ;
TIMESPEC TS_clk_2 = PERIOD : clk_2_grp : 8 ns ;
# spec inter clock domains
# clk_1 to clk_2
TIMESPEC TS_clk1x_2_clk2x = FROM : clk_1_grp : TO : clk_2_grp : 8 ns ;

I'll leave you to worry about the issues when clocks are unrelated in which
case, as you implied, the delay is irrelevant (clocks unrelated). If it were
me I'd be inclined to clock reg1 with clk_2 but add a "reg0" before it
clocked by clk_1, to shift the problem upstream a bit. I assume that the mux
select is semistatic and that you have considered the metastability issues
in place.

Regards,

Fred

Article: 35587
Subject: Exemplar : LUT's are ix & Nets are nx
From: "Nisreen Taiyeby" <nisreen@blr.paxonet.com>
Date: Thu, 11 Oct 2001 03:23:14 -0700
Links: << >> << T >> << A >>

I am a bit perplexed with the way nets and combinatorial logic is named in LeonardoSpectrum. Nets are named as "nx followed by a number", and similarly with LUT's and combinatorial logic, i.e ix followed by a number".

Now if I wish to Lock certain LUT's in a particual CLB location,  then I have no clue about which Lut to pick up , since they all look so dumb and clueless themselves. So hpw does one recognise combinatorial logic.
To add further to this confusion, each time I re-synthesize my design, Leonardo assigns a new number to those LUT's which I painstakingly identified earlier.

Hence my point here is that though Exemplar has a provision to identify registers with reg_, which can be changed by user with this variable called  "prepend_dff_inst_name",why is it overlooking this sort of thing for combinatorial logic also.

Just a wild idea, I was wondering if we could write a tcl script for this kind of a thing.

Please help and advice,

Nisreen Taiyeby

Article: 35588
Subject: I found the error
From: Andrew Gray <s9813479@student.up.ac.za>
Date: Thu, 11 Oct 2001 12:28:18 +0200
Links: << >> << T >> << A >>

Thanks

I found the error.

The last line should have read: clr_alloc_shift <= '0';
and not: clr_alloc_shift <= '1';

The asynchronous reset of the shift register is active high.

Andrew

Article: 35589
Subject: Re: High level synthesis will never work well :)
From: =?ISO-8859-1?Q?L=E4hteenm=E4ki?= Jussi <jusa@cc.tut.fi>
Date: Thu, 11 Oct 2001 10:29:35 +0000 (UTC)
Links: << >> << T >> << A >>

Don Husby <husby_d@yahoo.com> wrote:

	I dont know that much about verilog, but what I see in your
code is (in my opinion :) ) a synchronous reset, which ofcourse can
not be fed directly to the asynchronous reset inputs of the flip-flops.
Furthermore, we cannot implement such a huge counter with only 56 LUTs. 
Normally, LUTs are say 4 input memory blocks, in which case we can do 
any logical function of four inputs and one output. However, the highest 
bit of the 56-bit counter needs the 55 lower bits in its enable input 
plus the one used for enabling the actual counter. This is true for all 
the bits, which increases the number of LUTs signicantly. I would bet 
that 8-bit counter of the same type would consume about 12 LUTs (without
knowing the targer device).

So the counter is actually very optimized, its the designer who is not
in this case :) Furthermore, counters synthesize very efficiently in 
todays tools, if used properly (the hdl code is clear). In any 
commercial product I would advise to construct all counters from smaller
counters, say 4-bit counters. It eases the final production testing.

cya,
juza 

: (Note that this sort of thing isn't specific to
: Synplicity.  Leonardo does a lot of wacky things too.
: Sadly, Synplicity is probably the better tool.)

: You'd think a simple 56-bit counter would be no
: problem.  The code below should synthesize to
: 1 logic level using 56 LUTs, 56 FFs and a carry chain.
: Instead, Synplicity adds an extra 57 LUTs and an extra
: level of logic.

:   module Cnt56(K, CE, R, Out);
:     input         K, CE, R;
:     output [55:0] Out;
:     reg    [55:0] Q;
:     assign Out= Q;
:     always @(posedge K) Q <= R ? 0 : CE ? Q+1 : Q;
:     // if (R)       Q <= 0;    // This doesn't work either
:     // else if (CE) Q <= Q+1;
:   endmodule

Article: 35590
Subject: Re: High level synthesis will never work well :)
From: "Andrew Brown" <andrewbr@nortelnetworks.com>
Date: Thu, 11 Oct 2001 12:02:23 +0100
Links: << >> << T >> << A >>

The designers code was very clear and stated exactly what he wanted !  Maybe
synthesis vendors forget that their tools should synthesis out code - we
won't code to suit them.  Code should be oriented toward fast and efficient
simulation where most designer time is spent.  I wouldn't change code just
to make synthesis work a little better (back to the point about not minding
a few extra gates).  But i do expect synthesis tools to learn how to
implement the code better - as for the architecture - the origional post
didn't specify the device (xilinx infered?) so i don't know if an explicit
synchronous reset is available - i assume it is - in which case it should
have been used.

A.

P.S. since we started on coding style :? is outlawed in C these days - it
should probably so the same way in verilog !

"Lähteenmäki Jussi" <jusa@cc.tut.fi> wrote in message
news:9q3saf$hqh$1@news.cc.tut.fi...
> Don Husby <husby_d@yahoo.com> wrote:
>
> I dont know that much about verilog, but what I see in your
> code is (in my opinion :) ) a synchronous reset, which ofcourse can
> not be fed directly to the asynchronous reset inputs of the flip-flops.
>
> So the counter is actually very optimized, its the designer who is not
> in this case :) Furthermore, counters synthesize very efficiently in
> todays tools, if used properly (the hdl code is clear). In any
> commercial product I would advise to construct all counters from smaller
> counters, say 4-bit counters. It eases the final production testing.
>
> cya,
> juza

Article: 35591
Subject: Re: qpsk clock recovery
From: eas@bi.net.tr (eas)
Date: 11 Oct 2001 05:12:33 -0700
Links: << >> << T >> << A >>

"Bhaskar Thiagarajan" <bhaskart@my-deja.com> wrote in message news:<9q1sqq$loqqh$1@ID-82263.news.dfncis.de>...
> Clock recovery is a very important part of receivers and is discussed pretty
> much in every communications text. There are various methods to perform this
> function, but some of the common methods are well described (Ray just
> described one using PLLs).
> If you want to perform this block in real time at that kind of data
> rates...FPGAs/ASICs are your only choice. But if you can store a large
> amount of data and post process this, you can probably do this on a DSP.
> Search for key words like clock recovery, Costas Loop, etc. I doubt if you
> will find detailed examples of implementation other than descriptions on how
> this is typically done.
> --
> Cheers
> Bhaskar
> Note: I do *not* check the listed email address.
> 

OK. Now I have to ask some question:
1. Where can I find the basic building blocks examples to perform the
clock recovery in FPGA?
2. Some texts explain clock recovery for NRZ data, How should I
process IQ data to put in a suitable form?
3. I read a text that DPLL is suitable for data rates <10Mbps. Is this
true?

Thanks

Article: 35592
Subject: Re: Virtex2 DCM: frequenqy synthesis
From: "Apllehead" <aline_delawa@new.labour.org.uk>
Date: Thu, 11 Oct 2001 15:13:08 +0200
Links: << >> << T >> << A >>


This is from the Virtex II data book ver. 1.7 (The latest)
        Frequency Synthesis
        Table 37: Frequency Synthesis
        Attribute Min Max
        CLKFX_MULTIPLY 2 32
        CLKFX_DIVIDE 1 32

CLKFX_MULTIPLY = M
CLKFX_DIVIDE = D

M = 100 is outside of range 2 - 32

In the preliminary spec the ranges were
        CLKFX_MULTIPLY 2 4096
        CLKFX_DIVIDE 1 4096






Hermann Winkler <hermann.winkler@array-electronics.de> wrote in message
news:3bc452e4$0$190$4d4ebb8e@read.news.de.uu.net...
> I have seen previous discussion concerning frequency synthesis
> with DCM. As far as I remember there are restrictions on the
> combinations of M/D. M is the multiplication factor and D
> is the division factor of the input frequency.
>
> I am working now on a design for a XCV2 2000 that uses an internal
> clock of 100 MHz. This clock is generated by a DCM from an
> external clock source of 27 MHz. Therefore, my M/D is 100/27.
>
> Does the DCM support M/D=100/27 ?
>
> Hermann Winkler
>
>
>

Article: 35593
Subject: Re: FPGA reset
From: Ray Andraka <ray@andraka.com>
Date: Thu, 11 Oct 2001 13:53:10 GMT
Links: << >> << T >> << A >>

GSR is a dedicated net into the FF, which is in addition to, and independent of
the S/R input you see in the drawings.  The signals are essentially OR'd.  As
others have mentioned, you can't depend on the GSR signal propagating through the
whole tree within a clock cycle even if you synchronize it to the clock if your
clock is anywhere near what the FPGA is capable of.  You need to use GSR to get
it to known start state and not allow anything to strat 'moving' until some delay
after GSR goes so that you allow multiple clock cycles for GSR to go away.

Hal Murray wrote:

> >Just a note on using GSR-not using GSR with synthesis.  GSR routing is free,
> >it is dedicated copper...and can be used for nothing else.  If you do NOT
> >use GSR, and have a reset in your design (as you probably should) you are
> >using regular routing resources for this possibly very prolific global net.
> >In order for synthesis to use GSR (at least Synplicity) EVERY flop must be
> >attached to GSR, or it will use regular routing resources.
>
> Thanks for the reminder.
>
> How come all the pictures in the Xilinx data sheets telling us
> where the muxes are and which signals go where don't show the GSR
> signal?  (Am I just missing it?)
>
> Is GSR a not-shown input to some mux or is there an extra GSR
> input on the FF that's not shown?  Does GSR get ORed with the
> set/reset the picture shows?  If I trick the tools into using
> the GSR signal, am I wasting the normal set/reset logic?  (Or
> are the tools smart enough to use them too, if the hardware
> supports that?)
>
> --
> These are my opinions, not necessarily my employeers.  I hate spam.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759

Article: 35594
Subject: Re: High level synthesis will never work well :)
From: Ray Andraka <ray@andraka.com>
Date: Thu, 11 Oct 2001 13:56:02 GMT
Links: << >> << T >> << A >>

If you have a global reset in your design, synplicity won't also use the reset
input to the FF because it doesn't recognize the global reset as being a hidden
dedicated net.  I still have not found a satisfactory work around for this.

Andrew Brown wrote:

> The designers code was very clear and stated exactly what he wanted !  Maybe
> synthesis vendors forget that their tools should synthesis out code - we
> won't code to suit them.  Code should be oriented toward fast and efficient
> simulation where most designer time is spent.  I wouldn't change code just
> to make synthesis work a little better (back to the point about not minding
> a few extra gates).  But i do expect synthesis tools to learn how to
> implement the code better - as for the architecture - the origional post
> didn't specify the device (xilinx infered?) so i don't know if an explicit
> synchronous reset is available - i assume it is - in which case it should
> have been used.
>
> A.
>
> P.S. since we started on coding style :? is outlawed in C these days - it
> should probably so the same way in verilog !
>
> "Lähteenmäki Jussi" <jusa@cc.tut.fi> wrote in message
> news:9q3saf$hqh$1@news.cc.tut.fi...
> > Don Husby <husby_d@yahoo.com> wrote:
> >
> > I dont know that much about verilog, but what I see in your
> > code is (in my opinion :) ) a synchronous reset, which ofcourse can
> > not be fed directly to the asynchronous reset inputs of the flip-flops.
> >
> > So the counter is actually very optimized, its the designer who is not
> > in this case :) Furthermore, counters synthesize very efficiently in
> > todays tools, if used properly (the hdl code is clear). In any
> > commercial product I would advise to construct all counters from smaller
> > counters, say 4-bit counters. It eases the final production testing.
> >
> > cya,
> > juza

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759

Article: 35595
Subject: Re: High level synthesis will never work well :)
From: "Andrew Brown" <andrewbr@nortelnetworks.com>
Date: Thu, 11 Oct 2001 15:15:46 +0100
Links: << >> << T >> << A >>

You shouldn't have to find a work around. Yes, i know that workarounds are a
necessary part of development - unfortunately - but if this has been
happening for a while synplicity should note the issue and resolve their
problem.  I forgot to check to see if the origional poster used th global
reset (GSR) which probably shouldn't be used here (it is applied to all
logic andnot just a local counter) unless of course the counter is the only
logic !


"Ray Andraka" <ray@andraka.com> wrote in message
news:3BC5A521.D21FBCB1@andraka.com...
> If you have a global reset in your design, synplicity won't also use the
reset
> input to the FF because it doesn't recognize the global reset as being a
hidden
> dedicated net.  I still have not found a satisfactory work around for
this.

Article: 35596
Subject: Re: High level synthesis will never work well :)
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Thu, 11 Oct 2001 14:39:28 GMT
Links: << >> << T >> << A >>

On Thu, 11 Oct 2001 13:56:02 GMT, Ray Andraka <ray@andraka.com> wrote:

>If you have a global reset in your design, synplicity won't also use the reset
>input to the FF because it doesn't recognize the global reset as being a hidden
>dedicated net.  I still have not found a satisfactory work around for this.

Hi Ray,

It used to recognise the global reset.  This led to a problem with
6.0.0 in that it would remove the redundant reset from the EDIF which
in turn meant that it didn't retain the reset value (0 or 1) that you
had asked for.  The back end tools would substitute the default (0).

Bad luck if you wanted 1.

AFAIK I was the first user to report this bug (and it took some weeks
to convince them that it was a bug).  I wonder if the fix in more
recent versions of Synplify involved removing the ability to recognise
the use of GSR?

Regards,
Allan.

>Andrew Brown wrote:
>
>> The designers code was very clear and stated exactly what he wanted !  Maybe
>> synthesis vendors forget that their tools should synthesis out code - we
>> won't code to suit them.  Code should be oriented toward fast and efficient
>> simulation where most designer time is spent.  I wouldn't change code just
>> to make synthesis work a little better (back to the point about not minding
>> a few extra gates).  But i do expect synthesis tools to learn how to
>> implement the code better - as for the architecture - the origional post
>> didn't specify the device (xilinx infered?) so i don't know if an explicit
>> synchronous reset is available - i assume it is - in which case it should
>> have been used.
>>
>> A.
>>
>> P.S. since we started on coding style :? is outlawed in C these days - it
>> should probably so the same way in verilog !
>>
>> "Lähteenmäki Jussi" <jusa@cc.tut.fi> wrote in message
>> news:9q3saf$hqh$1@news.cc.tut.fi...
>> > Don Husby <husby_d@yahoo.com> wrote:
>> >
>> > I dont know that much about verilog, but what I see in your
>> > code is (in my opinion :) ) a synchronous reset, which ofcourse can
>> > not be fed directly to the asynchronous reset inputs of the flip-flops.
>> >
>> > So the counter is actually very optimized, its the designer who is not
>> > in this case :) Furthermore, counters synthesize very efficiently in
>> > todays tools, if used properly (the hdl code is clear). In any
>> > commercial product I would advise to construct all counters from smaller
>> > counters, say 4-bit counters. It eases the final production testing.
>> >
>> > cya,
>> > juza
>
>--
>--Ray Andraka, P.E.
>President, the Andraka Consulting Group, Inc.
>401/884-7930     Fax 401/884-7950
>email ray@andraka.com
>http://www.andraka.com
>
> "They that give up essential liberty to obtain a little
>  temporary safety deserve neither liberty nor safety."
>                                          -Benjamin Franklin, 1759
>
>

Article: 35597
Subject: Re: Virtex2 DCM: frequenqy synthesis
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 11 Oct 2001 08:03:39 -0700
Links: << >> << T >> << A >>

All,

In careful characterization of the DCM, we decided to limit the M and D
values to those that delivered acceptable jitter performance, and could be
covered by the production test.

I am sure one can appreciate the problem of testing 2E403 frequency/M/D
combinations.  By limiting the universe to 32, and not allowing any
fraction that has not been reduced to its least common denominator, we also
reduce the test space to one that is reasonable.

One of the big advantages of a pure digital circuit should be that its
behavior is always predictable.  In order to supply that level of quality,
we must sometimes limit the features to those we can stand behind.

I apologize to anyone who may have been counting on large M and D values.
It was never our intent to mislead anyone, and we would have removed all
references to M and D ranges in the preliminary data sheets if we would
have caught them in time.  As it was, it was something that slipped through
the review process, and I hold myself accountable as the chief organizer of
the datasheet review for technical accuracy of Virtex II's advanced
datasheet.

Austin

Apllehead wrote:

> This is from the Virtex II data book ver. 1.7 (The latest)
>         Frequency Synthesis
>         Table 37: Frequency Synthesis
>         Attribute Min Max
>         CLKFX_MULTIPLY 2 32
>         CLKFX_DIVIDE 1 32
>
> CLKFX_MULTIPLY = M
> CLKFX_DIVIDE = D
>
> M = 100 is outside of range 2 - 32
>
> In the preliminary spec the ranges were
>         CLKFX_MULTIPLY 2 4096
>         CLKFX_DIVIDE 1 4096
>
> Hermann Winkler <hermann.winkler@array-electronics.de> wrote in message
> news:3bc452e4$0$190$4d4ebb8e@read.news.de.uu.net...
> > I have seen previous discussion concerning frequency synthesis
> > with DCM. As far as I remember there are restrictions on the
> > combinations of M/D. M is the multiplication factor and D
> > is the division factor of the input frequency.
> >
> > I am working now on a design for a XCV2 2000 that uses an internal
> > clock of 100 MHz. This clock is generated by a DCM from an
> > external clock source of 27 MHz. Therefore, my M/D is 100/27.
> >
> > Does the DCM support M/D=100/27 ?
> >
> > Hermann Winkler
> >
> >
> >

Article: 35598
Subject: Re: Dual Port Fifo for Virtex II
From: Peter Alfke <palfke@earthlink.net>
Date: Thu, 11 Oct 2001 15:07:38 GMT
Links: << >> << T >> << A >>

What do you mean by "dual-port FIFO"
Most FIFOs are implemented using a dual-port memory, one port for write, the
other one for read. Is that what you mean?

Peter Alfke
============================
Philippe Robert wrote:

> Hi there,
>
> I have been working on a vhdl design for a Virtex II for a little while now
> and I would need to implement Dual Port Fifo. Does anyone have such a block,
> or where I could get one ?
>
> Rgds.
> Philippe.

Article: 35599
Subject: DCM simulation results do not match part spec's
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Thu, 11 Oct 2001 11:29:45 -0400
Links: << >> << T >> << A >>

Hi,
    I have a simulation running using the most recent version of
web-pack.  I am simulating a DCM using it to generate the 4 quadurature
outputs (0, 90, 180, and 270 degrees).  Frequency multiplication is 1.
I am giving it a 400 MHz clock and the simulation still shows proper
signals with no errors on these outputs.  In fact, all the outputs seem
correct on this part.  This is the slower version in the simulation.  (I
am using the most recent version of the web pack software.)  What
gives?  How do I really simulate this part and get proper results that I
can trust?

    By the way, I am using two DCM's to generate 8 clocks with 45 degree
spacing.  These clocks are driving 8 counters who's outputs are summed
to get an equivalent output with 8 times the resolution of the input
clock.  Thanks to Peter Alfke for the idea.

    Here is a section of the input code for the two DCM's

attribute DFS_FREQUENCY_MODE : string;
attribute CLKFX_DIVIDE : integer;
attribute CLKFX_MULTIPLY : integer;
attribute STARTUP_WAIT : string;
attribute CLKOUT_PHASE_SHIFT  : string;
attribute PHASE_SHIFT : integer;

attribute DFS_FREQUENCY_MODE of DCM_1: label is "LOW";
attribute CLKFX_DIVIDE of DCM_1: label is 1;
attribute CLKFX_MULTIPLY of DCM_1: label is 1;
attribute CLKOUT_PHASE_SHIFT  of DCM_1: label is "FIXED";
attribute STARTUP_WAIT of DCM_1: label is "FALSE";
attribute PHASE_SHIFT of DCM_1: label is 0;

attribute DFS_FREQUENCY_MODE of DCM_2: label is "LOW";
attribute CLKFX_DIVIDE of DCM_2: label is 1;
attribute CLKFX_MULTIPLY of DCM_2: label is 1;
attribute CLKOUT_PHASE_SHIFT  of DCM_2: label is "FIXED";
attribute STARTUP_WAIT of DCM_2: label is "FALSE";
attribute PHASE_SHIFT of DCM_2: label is 32;

begin

DCM_1:DCM
  port map (
            CLKIN =>    clock,
            CLKFB => clock0,
           DSSEN  => zero,
           PSINCDEC => zero,
           PSEN     => zero,
           PSCLK    => zero,
           RST      => rst,
           CLK0     => clock0,
           CLK90    => clock90,
           CLK180   => clock180,
           CLK270   => clock270,
           CLK2X    => open,
           CLK2X180 => open,
           CLKDV    => open,
           CLKFX    => open,
           CLKFX180 => open,
           LOCKED   => open,
           PSDONE   => open,
           STATUS   => open
    );

DCM_2:DCM
  port map (
            CLKIN =>    clock,
            CLKFB => clock45,
           DSSEN  => zero,
           PSINCDEC => zero,
           PSEN     => zero,
           PSCLK    => zero,
           RST      => rst,
           CLK0     => clock45,
           CLK90    => clock135,
           CLK180   => clock225,
           CLK270   => clock315,
           CLK2X    => open,
           CLK2X180 => open,
           CLKDV    => open,
           CLKFX    => open,
           CLKFX180 => open,
           LOCKED   => open,
           PSDONE   => open,
           STATUS   => open
    );



Thanks,
Theron Hicks

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

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