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 40200

Article: 40200
Subject: Re: stuck in state in Spartan-II!
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Fri, 1 Mar 2002 20:29:06 +0100
Links: << >>  << T >>  << A >>
"Ken Mac" <aeu96186@yahoo.co.uk> schrieb im Newsbeitrag
news:a5o4kv$spj$1@dennis.cc.strath.ac.uk...
>
> I am not using a PLL outside (I don't think - would the DAC have one?).

Could be.

> clk33 comes in on a pin and is fed through a DLL to the design.
> clk425 also comes in on a pin and is fed through a DLL to the design.
^^^^^^^^^^^^
^this is rarely possible. A DLL works only on clock signals with frequencies
>25 MHz. And they must be continous, no gapped clock or similar tricks.

--
MfG
Falk





Article: 40201
Subject: Re: Pin assignments in QUARTUS
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 01 Mar 2002 11:39:45 -0800
Links: << >>  << T >>  << A >>
Luigi wrote:

> assigning 500 pins with my mouse wouldn't have been a good way to use
> my time, especially if I have to floorplan more than one time...

So why not use your text editor on the .csf file like 
Jean-Baptiste suggested?

  -- Mike Treseler

Article: 40202
Subject: simulating time_sim.vhd file
From: lapraveen@yahoo.com (praveen)
Date: 1 Mar 2002 11:46:12 -0800
Links: << >>  << T >>  << A >>
hello,

I'm using Xilnx Foundation Tool(4.1i) to map some of my designs. In
the process I want to simulate the "time_sim.vhd" file that is
generated in the timing simulation phase of the (Implementation) flow
engine.

Can anyone suggest me a method (apart from using Modelsim Simlator to
do the same)?

thanks.

regards
Praveen

Article: 40203
Subject: Re: Altera FPGAs
From: prashantj@usa.net (Prashant)
Date: 1 Mar 2002 11:47:00 -0800
Links: << >>  << T >>  << A >>
Hi,

Thanks. It seems I was looking at delays which involve the
input/output pin delays too. When I registered my inputs and outputs
and measured the register-to-register delay, the delay is much lesser
(<20ns). I put 2 multipliers in series one after another. The second
one takes an input from the previous multiplier output. This gives a
delay of about 10ns. These definitely make more sense.

For people with Xilinx software experience (ISE Webpack).... Where can
I get a trace report ? The synthesis report says that accurate timing
information is available in a trace report produced after place and
route. I see some reports after place and route, but none are called
trace reports. Any ideas ??

Thanks.
Prashant


"Peter Ormsby" <faepete.deletethis@mediaone.net> wrote in message news:<f9Df8.10278$Or3.1089192@typhoon.mn.ipsvc.net>...
> Prashant <prashantj@usa.net> wrote in message
> news:ea62e09.0202281345.1467d3c2@posting.google.com...
> 
> If anything, the 20K1500E is going to be slower than the 20K160E.  However,
> you should be able to get much faster speeds out of your 20K160E than you
> are currently seeing.
> 
> Make sure that your inputs and outputs are registered.  It takes a
> relatively long time for a signal to go between the pins and the FPGA
> routing structure, so it's helpful to move the inputs into a register before
> running them though the multiplier and then registering the multiplier
> outputs before running them off the chip.
> 
> Once you have the inputs and outputs registered, you should be able to get a
> multiplier working about 50MHz with no pipeline stages or over 110 MHz with
> two stages in a 20K160E.  You can use the Megawizard to create a pipelined
> multiplier without having to figure out the partial products implementation
> yourself.
> 
> Let me know if this doesn't help.
> 
> -Pete-

Article: 40204
Subject: Re: Beginner Altera Questions
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Sat, 02 Mar 2002 08:50:51 +1300
Links: << >>  << T >>  << A >>
jerry1111 wrote:
> 
> What to do when I have negative reset (as usual with uP)
> and I connect reset signal to fpga, but internal ffs wants to
> get positive reset (f.e. MAX3000). When I place inverter
> and all ffs are feed from inverted signal I got messages
> 'non global signal usage may result'.

Some (older) CPLDs do not support either global polarity.
Atmel ATF1502AS is close to MAX3000, and does have either 
Global Reset choice.
 
<paste> jerry
> And what means that message 'signal usage may not be global' or sth like that
> is generated?
> Are there any disadvantages other than some delays in clock propagation?
> Can I safely ignore this message? (Part runs OK with this message) or there
> are 'hidden' things happenig when such message is generated?

It means product terms are being used to generate the required polarity.
This adds a slight delay, but a RESET is not normally 'delay paranoid'.

More important, is there is less resource for more usefull logic.

Al Williams wrote:
> 
> True, but what if you want to get tricky and have one flip flop latch
> on the rising edge and another latch on the falling edge? This seems
> to work, but it does whine about the clock not being global.
> 
> I haven't tried it, but I was wondering if you could invert the clock
> and then feed it through a global buffer (assuming you haven't used
> all the global buffers). Don't know if that'd work or not.

 I know this works on the ATF1502AS. 
Dual edge clock work is getting more common, but even the venerable 
i2c bus has this.

-jg

Article: 40205
Subject: Re: Altera Excalibur
From: "Paul" <nospam@nospamplease.com>
Date: Fri, 1 Mar 2002 20:15:46 -0000
Links: << >>  << T >>  << A >>
Couldn't you try out one of the many free processor cores as well.
You could probably synthesise this for your Nios board.

e.g. the Leon sparc processor

I thought the Nios was extremely good value considering the wealth of tools,
board, software etc.

Paul

"jerry1111" <jerry1111@wp.pl> wrote in message
news:a5oj6f$mjh$1@news.tpi.pl...
> Hello,
>
> I want to buy Altera's softcore uP.
> Which one: Nios-based or Arm-based?
> Any suggestions?
> Before spending money for development tools I'd like
> to know the good and bad news for it.
>
> Is it possible to move from Nios to Arm-based without
> spending lot of money for Arm option (already having
> Nios purchased)?
>
> Thanks
>
> jerry
>
>



Article: 40206
Subject: Re: Rising and falling edge of a clk
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Fri, 01 Mar 2002 12:34:27 -0800
Links: << >>  << T >>  << A >>
O.K. as I wrote: "double-buffering would help", and that's what you are doing.
Sorry for my insulting assumptions  ;-)
Ray already mentioned that 155 MHz would be o.k. if you floorplan accorcingly.
Are you using Virtex-II? You probably know that you can read out data at a
different width, if that helps you. In your case, you can read out 16 bits wide,
although you wrote 32 bits wide. Provided the speed is right.

Greetings
Peter Alfke, Xilinx Applications


"H.L" wrote:

> Hi Peter, thanks for your reply
> I was confident of this method's effectiveness but now I am worried :)) . I
> have already done a timing analysis in the paper and also the simulation
> waveforms seem promising.
> I didnt understand what do you mean when telling me that one of my words
> arrives early and the other one late. The transmitter sends to my FPGA an
> external clock (thats the 155MHz clock), a valid signal (1 bit indicating
> the transmission time period) and of course the 16-bit words that I have to
> store. Every clock period (~6 ns) I have available in my ports one 16-bit
> word, I register two sequential words from the in port to a 32-bit register
> (31->16 the first incoming word, 15->0 the second one). Then , in another
> 32-bit register I register (2 nd time) the 32-bit word I just "made" which
> are the BRAM data_in. All the above operations are in a process that has in
> its sensitivity list the 155 clock. I write to the BRAM at 77MHz  using the
> incoming clock divide by 2 using a DLL. BRAM input signals are assigned in
> the falling edge of the 77MHz clock so as to be before the rising edge (of
> the same clock) where the BRAM samples them. The write operations are in
> another process with the slow clock in its sensitivity list.
> The timing waveforms of the simulation are the same with the timing analysis
> in paper but does this is a valid hardware design technique?
> Thanks for your time and help!
>
> Best Regards,
> Harris
>
> p.s: thats a small part of my design. I use DLL because other parts need
> them (BUS_MUX e.t.c) , I tried to implement my whole design @ 155 MHz and I
> got many timing errors (floorplanning managed to reduce them but still lot
> of work to be done)
>
> "Peter Alfke" <peter.alfke@xilinx.com> wrote in message
> news:3C7E621F.1E77A244@xilinx.com...
> > I suggest you grab pencil and paper and do a clock-by-clock timing
> analysis. You
> > will find that your clock-speed reduction buys you nothing, unless you
> also
> > double-buffer the data.
> > One of your words arrives nice and early, the other one late. However you
> clock
> > the BRAM, one of the two words has the same old short set-up time...
> > Double-buffering would help. But Ray has mentioned some neat tricks to
> avoid the
> > long set-up time of the control inputs.
> >
> > I will get back with more constructive notes. "Gotta run"
> >
> > Peter Alfke
> > ===================
> > "H.L" wrote:
> >
> > > Hello all,
> > >
> > > I have a module that accepts 16 bit words at 155MHz and I want to store
> then
> > > in an 128x32 BRAM. I am going to use a DLL (in a Virtex-E FPGA) to
> divide by
> > > 2 the 155MHz clock as this frequency seems to be pretty high to write in
> the
> > > BRAM. So far I think 2 processes are enough to do my job, one operating
> @
> > > 155MHz to accept the 16-bit data and store them in a 32-bit register and
> the
> > > another one @ 75MHz to write the content of the 32-bit register in the
> BRAM.
> > > I am thinking to assign the BRAM's signals
> (ENABLE,WRITE,ADDRESS,DATA_IN) in
> > > the falling edge of the 75MHz clock, the main reason for this is the
> setup
> > > time of the BRAMs signals (in this way the address,data are 6 ns before
> next
> > > rising edge of the clock where BRAM samples its inputs). My question now
> :)
> > > , if one process uses the falling edge of one clock does this causes
> > > problems to other processes in the design , e.g to processes that use a
> > > different clock or to  processes using the rising edge of the same
> clock?
> > >
> > > Best Regards,
> > > Harris.
> >


Article: 40207
Subject: Re: PCI book ... still confused
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Fri, 01 Mar 2002 15:40:02 -0600
Links: << >>  << T >>  << A >>
That is good that you already got the specification.
Although, I sounded like PCI Hardware & Software isn't too important, 
it gives more waveform examples than the specification, so you might
find it helpful from time to time.
However, this book is not a book a designer should try to read through
the whole thing to learn PCI bus because that will take enormous amount
of time (I tried to do so about three years ago, but got discouraged,
and quit.).
Instead, read the section relevant to the part you are implementing at
the time.
        Regardless, the book is only a bus protocol book, so the devils
will be in the implementation, especially so in FPGAs (At least, Xilinx
claims that at LogiCORE PCI website. I have never even touched ASIC
tools, so I don't have a way to independently verify that claim, but it
is likely true.).
As long as the levels of 4-input LUT for unregistered signal paths are
low (3 levels if the routing distance is short, 1 level or 2 levels if
the routing distance is long.) meeting Tsu < 7ns for 33MHz PCI should
not be a major issue for Spartan-II-5 class FPGA.




Kevin Brace (Don't respond to me directly, respond within the
newsgroup.)




Matthias Scheerer wrote:
> 
> Hi Kevin,
> 
> I forgot to say that we already have the PCI Spec, which is actually the
> basis of our development. Due to your comment I think PCI Hardware and
> Software will be right for us.
> 
> Thanks for the comprehensive answer.
> 
> Matthias
>

Article: 40208
Subject: Re: stuck in state in Spartan-II!
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Fri, 01 Mar 2002 15:14:46 -0800
Links: << >>  << T >>  << A >>

--------------48BC095289FFAC626EAB9B38
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit

Here is a simple and robust handshake circuit.
http://support.xilinx.com/support/techxclusives/MovingData-techX16.htm
Peter Alfke, Xilinx Applications

rickman wrote:

> I would continue to use the 425 kHz clock to clock the DAC.  I would
> then use the rising edge of this clock to latch the data out to the DAC
> data pins.  I belive the 425enable signal can just tell the 33 MHz
> Process B to load new data into the previous register.
>
> But I actually would have done your processes a little differently.  One
> of the nice things about the memory in a Spartan II is that they are
> dual ported with independent clocks.  Unless you need a control signal
> (like Empty or Full) passing between the two domains, you could easily
> move data without the messy metastability issues.
>
> Actually, you HAVE to have some controls passing between the two clock
> domains because there has to be a counter that increments when you put
> data in and decrements when you take data out.  But this is very easy
> and is essentially like the syncing you did on the 425EN signal.  But it
> would eliminate the Process B logic.  The wide difference in clock
> speeds makes this a much simpler problem.  I assume that you are writing
> blocks of data to the FIFO?  If you are responding to each word that is
> read out to the DAC, then you don't need the FIFO, right?
>
> Ken Mac wrote:
> >
> > Phil,
> >
> > Forgot to mention that the DAC is fed the 425kHz clock via a pin of my
> > Spartan-II.
> >
> > The DAC uses the negative edges of the 425kHz clock to take data from
> > process C.
> >
> > Process C uses the positive edges of the 425kHz clock to place data on the
> > serial data pin for the DAC and the negative edges then drive the DAC.
> >
> > My DAC output now seems to be irregular - what signal should I use to clock
> > my DAC now?
> >
> > Thanks again,
> >
> > Ken
> >
> > > > Process A:    Runs at 33MHz to fill a 16 location FIFO with 8-bit data
> > > > samples and then keep it full.
> > > > Process B:    Runs at 33MHz to take data from the FIFO when told to and
> > > > supply it to process C via a register.
> > > > Process C:    Runs at 425kHz and sends FIFO 8-bit data samples to a DAC
> > > > bit-serially then asks process B for next piece of data.
> > >
> > > > Process A is fed with data via a Visual C++ app (the Spartan-II is
> > mounted
> > > > on a PCI board) which is synchronised with the FPGA using an interrupt
> > pin
> > > > that the FPGA can assert and the C++ can read.
> > > >
> > > > I have used this system for many designs with no trouble (none of them
> > had
> > > > multiple clock domains however).  The problem here is that the design is
> > > > getting stuck in state for no apparent reason!  (i.e. the C++ hangs
> > waiting
> > > > for the interrupt pin!).
> > >
> > > Sounds to me like you have a problem crossing clock domains.
> > >
> > >
> > > > The system works for a random number of samples (between 28 and 33 it
> > seems)
> > > > and then gets stuck in state. This is very strange because it means that
> > my
> > > > protocols do work.
> > >
> > > Not strange at all.  Suppose we have two registers in one clock domain
> > sampling
> > > a signal from the other clock domain.  If both get the same value for the
> > next
> > > clock, the logic works.  If only one gets the value, the logic hangs.
> > >
> > >
> > > > The weird thing is that I put a piece of debug code in another state to
> > send
> > > > a signal out to a pin to probe, I ran the flow again to get a bitstream
> > and
> > > > the system ran perfectly for all 75001 samples I am using!  The debug
> > code
> > > > was "Debug <= '1'".
> > >
> > > Different placement, different routing, different timing, different odds
> > of
> > > failure.  Might work well at 25C, and fail like above at 28C.
> > >
> > > > Then I enabled clock DLLs using the BUFGDLL component and it hangs
> > again!
> > >
> > > Different timing, different odds of failure.
> > >
> > >
> > > > Previously, I had it working perfectly using the clock DLLs but without
> > a
> > > > FIFO (i.e. 1 sample at a time from C++ to FPGA to DAC) but I got some
> > > > stutters hence I introduced the FIFO.
> > > >
> > > > In that design I also had hanging problems but after I rejigged my
> > protocol
> > > > in my VHDL state machines it worked perfectly.
> > > >
> > > > It seems that seemingly random changes of VHDL make or break the system.
> > I
> > > > guess it must be to do with my 2 different clock rates but that is the
> > way
> > > > it has to be.
> > > >
> > > > I am at a loss - anyone any ideas?
> > >
> > > First, sync the 425KHz to 33 MHz, then edge detect, and then use the edge
> > > detected clock 425 for a clock enable for process C.  Code fragments:
> > >
> > > process(clk33) begin
> > >   if rising_edge(clk33) then
> > >     synslow <= clk425;
> > >     synslow2 <= synslow;
> > >     synslow3 <= synslow2;
> > >     en425 <= synslow2 and not synslow3;
> > >   end if;
> > > end process;
> > >
> > > processc:
> > > process(clk33) begin -- was (clk425)
> > >   if rising_edge(clk33)
> > >     if en425 = '1' then -- was rising_edge(clk425)
> > >     ....
> > >
> > > The reason this (hopefully!) will solve your problem is that almost all
> > logic
> > > will be running on a single clock.  While there is a chance that synslow
> > will
> > > not correctly clock in clk425 on rising or falling edge ("go metastable"),
> > > synslow2 is much less likely to fail (As mean time between failures >> age
> > of
> > > universe), and en425 even less so.
> > >
> > > Also, you could synchronize all control signals between the two processes.
> > More
> > > complex.
> > >
> > >
> > > --
> > > Phil Hays
>
> --
>
> 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: 40209
Subject: Re: Synopsys Design Compiler
From: kayrock66@yahoo.com (Jay)
Date: 1 Mar 2002 15:20:16 -0800
Links: << >>  << T >>  << A >>
Thanks for giving me a reason to try "-k" again.  Unfortunately the
results are still a little inconclusive.
-k 4 1766 LUTs
-k 5 1766 LUTs
-k 6 1766 LUTs
-k 7 crash back to OS
-k 8 crash back to OS

I'm still running 3.3.08i.

Regards


acher@in.tum.de (Georg Acher) wrote in message news:<a5m848$d46$1@sunsystem5.informatik.tu-muenchen.de>...
> In article <d049f91b.0202281030.206aeb6b@posting.google.com>,
>  kayrock66@yahoo.com (Jay) writes:
> |> I'm trying to pitch that my client use Synopsys Design Compiler
> |> instead of an FPGA specific synthesizer from another vendor since his
> |> Xilinx Vertex 2 FPGA is a proto for a standard cell part.  The clock
> |> speed isn't important, verification of the tool flow and design
> |> database is.
> |> 
> |> The problem I'm running into is that the Design Compiler output uses
> |> almost 200% the LUTs compared to the purpose built FPGA synthesizer. 
> |> So the logic will no longer fit the proto board.
> |> 
> |> Mini Example:
> |> Design compiler: 1760 LUTS
> |> FPGA synthesizer: 824 LUTS
> |> 
> |> Design compiler synthesizes to cells like AND2, OR2, AND4, etc whereas
> |> the FPGA specific tool maps directly to special LUTs custom made for
> |> the logic required like LUT_AB5A and LUT_67FE, etc.  Now I figured the
> |> Xilinx mapper would be smart enough to "map" the Design Compiler AND2,
> |> OR2, etc, into more compact LUT_ABCD and LUT_6534 type cells but just
> |> seems to be doing a 1 for one map with no optimization.
> |> 
> |> It appears that Xilinx did not write the mapper optimization (option
> |> -oe) for the recent products Vertex E/2 an Spartan 2 in effect giving
> |> up support for Design Compiler.
> |> 
> |> Can any one else comment on this?  It seems crazy that I can't use the
> |> old man of sythesis (Design Compiler) at $100k seat anymore.
> 
> My last experiences with DC are only on the 4k-Series (now I'm using
> fpga_compiler2 for Spartan2), but maybe this helps:
> 
> "map -help spartan2" shows among others:
> 
>  -k 4|5|6          Function size for covering combinational logic.  If -k
>                        is not specified, the default is -k 4.  This gives the
>                        best balance of runtime to quality of results.  Using
>                        5 or 6 can give superior results at the expense of 
>                        runtime.
> 
> So try to use -k 6, this can make design much smaller (and faster...)
> 
> Have you used the usual tweaks in DC, like
> "compile -boundary_optimization -map_effort high" and
> "compile -map_effort high -ungroup_all" afterwards?
> 
> Are you sure that the reset net is replaced by the STARTUP-symbol and removed
> in the design ("disconnect_net reset -all")?

Article: 40210
Subject: Re: cross clock domain signals
From: "Paul Butler" <Paul.Butler@ni.com>
Date: Fri, 1 Mar 2002 17:23:05 -0600
Links: << >>  << T >>  << A >>

"Peter Alfke" <peter.alfke@xilinx.com> wrote:
> click on
> http://support.xilinx.com/support/techxclusives/fifo-techX18.htm
> The best Gray-code counter implementation actually starts with a
> binary counter and converts it, bit by bit, to Gray. Therefore, you
> can subtract the two binary count values, and then clean up the
> result with techniques described in my another paper
> http://support.xilinx.com/support/techxclusives/MovingData-techX16.htm

Good idea.  If you're writing VHDL, the VHDL below might give you some
ideas.

Paul Butler

library ieee;
use ieee.std_logic_1164.all;
use work.GrayPack.all;

entity GrayCounter is
  port(
    signal Clock : in std_logic;
    signal Reset : in boolean;
    signal DirectionUp : in boolean;
    signal CounterVal : out Gray
  );
end GrayCounter;

architecture RTL of GrayCounter is

  signal CurrentCount : Gray(CounterVal'range);

begin

  Process(Clock, Reset)
  begin
    if Reset then
      CurrentCount <= (others => '0');
    elsif rising_edge(Clock) then
      if DirectionUp then
        CurrentCount <= CurrentCount + 1;
      else
        CurrentCount <= CurrentCount - 1;
      end if;
    end if;
  end process;

  CounterVal <= CurrentCount;

end RTL;

--synthesis translate_off

entity test_GrayCounter is
end test_GrayCounter;

library ieee;
use ieee.std_logic_1164.all;
use work.GrayPack.all;

architecture behave of test_GrayCounter is
  component GrayCounter
  port(
    signal Clock : in std_logic;
    signal Reset : in boolean;
    signal DirectionUp : in boolean;
    signal CounterVal : out Gray
  );
  end component;

  signal Clock : std_logic;
  signal Reset : boolean;
  signal DirectionUp : boolean;
  signal CounterVal : Gray(7 downto 0);

  signal StopClock : boolean := false;

begin

  Stimulus:
  Process
  begin
    Reset <= true, false after 1 ns;
    DirectionUp <= true, false after 5 us;
    StopClock <= false, true after 10 us;
    while not StopClock loop
      Clock <= '0';
      wait for 50 ns;
      Clock <= '1';
      wait for 50 ns;
    end loop;
    wait;
  end process;

  DUT:  GrayCounter
    port map(
      Clock => Clock,
      Reset => Reset,
      DirectionUp => DirectionUp,
      CounterVal => CounterVal
    );

end behave;



-----------------------------------------------------

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

package GrayPack is

  type Gray is array (natural range<>) of std_ulogic;

  function To_Gray (arg : in unsigned) return Gray ;
  function To_unsigned (arg : in Gray) return unsigned ;

  function "+"(l : in Gray; r : in Gray) return Gray ;
  function "+"(l : in Gray; r : in integer) return Gray ;
  function "+"(l : in integer; r : in Gray) return Gray ;
  function "+"(l : in Gray; r : in unsigned) return Gray ;
  function "+"(l : in unsigned; r : in Gray) return Gray ;

  function "-"(l : in Gray; r : in Gray) return Gray ;
  function "-"(l : in Gray; r : in integer) return Gray ;
  function "-"(l : in integer; r : in Gray) return Gray ;
  function "-"(l : in Gray; r : in unsigned) return Gray ;
  function "-"(l : in unsigned; r : in Gray) return Gray ;

  function "-"(l : in Gray; r : in Gray) return unsigned ;
  function "-"(l : in Gray; r : in integer) return unsigned ;
  function "-"(l : in integer; r : in Gray) return unsigned ;
  function "-"(l : in Gray; r : in unsigned) return unsigned ;
  function "-"(l : in unsigned; r : in Gray) return unsigned ;

end GrayPack;

package body GrayPack is

  function To_Gray (arg : in unsigned) return Gray is
    variable result : Gray(arg'range);
  begin
    result := (others => '0');
    result(result'high) := arg(arg'high);
    for i in result'high-1 downto result'low loop
      result(i) := arg(i) xor arg(i+1);
    end loop;
    return result;
  end To_Gray;

  function To_unsigned (arg : in Gray) return unsigned is
    variable result : unsigned(arg'range);
  begin
    result(result'high) := arg(arg'high);
    for i in result'high-1 downto result'low loop
      result(i) := result(i+1) xor arg(i);
    end loop;
    return result;
  end To_unsigned;

  function "+"(l : in Gray; r : in Gray) return Gray is
  begin
    return To_Gray(To_unsigned(l) + To_unsigned(r));
  end "+";

  function "+"(l : in Gray; r : in integer) return Gray is
  begin
    return To_Gray(To_unsigned(l) + r);
  end "+";

  function "+"(l : in integer; r : in Gray) return Gray is
  begin
    return To_Gray(l + To_unsigned(r));
  end "+";

  function "+"(l : in Gray; r : in unsigned) return Gray is
  begin
    return To_Gray(To_unsigned(l) + r);
  end "+";

  function "+"(l : in unsigned; r : in Gray) return Gray is
  begin
    return To_Gray(l + To_unsigned(r));
  end "+";

  function "-"(l : in Gray; r : in Gray) return Gray is
  begin
    return To_Gray(To_unsigned(l) - To_unsigned(r));
  end "-";

  function "-"(l : in Gray; r : in integer) return Gray is
  begin
    return To_Gray(To_unsigned(l) - r);
  end "-";

  function "-"(l : in integer; r : in Gray) return Gray is
  begin
    return To_Gray(l - To_unsigned(r));
  end "-";

  function "-"(l : in Gray; r : in unsigned) return Gray is
  begin
    return To_Gray(To_unsigned(l) - r);
  end "-";

  function "-"(l : in unsigned; r : in Gray) return Gray is
  begin
    return To_Gray(l - To_unsigned(r));
  end "-";

  function "-"(l : in Gray; r : in Gray) return unsigned is
  begin
    return (To_unsigned(l)-To_unsigned(r));
  end "-";

  function "-"(l : in Gray; r : in integer) return unsigned is
  begin
    return (To_unsigned(l)-r);
  end "-";

  function "-"(l : in integer; r : in Gray) return unsigned is
  begin
    return (l-To_unsigned(r));
  end "-";

  function "-"(l : in Gray; r : in unsigned) return unsigned is
  begin
    return (To_unsigned(l)-r);
  end "-";

  function "-"(l : in unsigned; r : in Gray) return unsigned is
  begin
    return (l-To_unsigned(r));
  end "-";

end GrayPack;





Article: 40211
Subject: Re: Clock multiplier/ADPLL in PLD
From: John_H <johnhandwork@mail.com>
Date: Sat, 02 Mar 2002 00:04:55 GMT
Links: << >>  << T >>  << A >>
I stated that the DCMs need a 25MHz reference.

I read that the system has 44kHz.

I was suggesting using the parallel to an analog PLL rather than the DPLLs you
see in USB implementations which require significant timing content in the signal
the clock is derived from.

A phase error detector is emulated by a counter.

The 'filtering' is done with shifts and accumulators to mimic the analog filters.

The VCO is approximated with a phase accumulator that can leverage the DCMs and
global clock muxes to give better jitter characteristics than with a high
frequency clock alone.

The approach I tried to suggest goes into digital frequency synthesis with the
closed-loop approach of an Analog PLL.  A system can be designed without abrupt
changes in frequency and with other characteristics favorable to analog PLLs
without the noise issues inherent in the analog system.

My apologies if implementing an analog PLL in the digital realm is too much of a
deviation from the "classical" DPLL to effectively communicate the concept.

- John_H



Ray Andraka wrote:

> you are the second to mention the Xilinx DLLs/DCMs.  Unfortunately, they are
> of no use here since the input clock is only 44 KHz, and even the desired
> output is less than half the minimum frequency for those blocks.  As for the
> DPLL, it is not really a direct port from an analog PLL, there are usually no
> filters per se.  Instead, the 'filtering' is done by the counters.


Article: 40212
Subject: Re: Altera Excalibur
From: James Horn <jimhorn@svn.net>
Date: 1 Mar 2002 16:11:44 -0800
Links: << >>  << T >>  << A >>
The Excaliber ARM implimentation is hardware - a physical unit as part of 
the APEX chip, not a soft core.  Its  peripherals are soft, of course.

The NIOS, being a soft core, can be used in any Altera chip with the 
resources (6000 series on up), or even more than once per chip if you 
wish.

Jim Horn (Haven't used NIOS yet but preparing to - nice devel. kit!)

Article: 40213
Subject: Re: Pin assignments in QUARTUS
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Sat, 02 Mar 2002 00:13:24 GMT
Links: << >>  << T >>  << A >>


Luigi wrote:
> 
> rjshaw@iprimus.com.au (russell) wrote in message news:<c3771dbf.0202260036.edc1b91@posting.google.com>...
> > >...............
> > > boring interface of the "Assignment organizer". I cannot assign 500
> > > pins clicking with my mouse!
> >
> > Yes (in quartus2), open the node-finder, select "pins unassigned",
> > Named "*", then click "Start" to list all the pins.
> >
> > Now open "current assignments" floor-plan, and display the external
> > package view. Now just drag and drop the pins from the node-finder
> > window to the pins in the floor-plan window. Maxplus2 could do this,
> > so any version of quartus probably would too.
> 
> Ah, ok... when I said "I cannot assign 500 pins clicking with my
> mouse"...

I missed the mouse bit. I thought you meant
avoiding keyboard entry.

Article: 40214
Subject: Re: Synopsys Design Compiler
From: acher@in.tum.de (Georg Acher)
Date: 2 Mar 2002 00:29:55 GMT
Links: << >>  << T >>  << A >>
In article <d049f91b.0203011520.2aa59f8d@posting.google.com>,
 kayrock66@yahoo.com (Jay) writes:
|> Thanks for giving me a reason to try "-k" again.  Unfortunately the
|> results are still a little inconclusive.
|> -k 4 1766 LUTs
|> -k 5 1766 LUTs
|> -k 6 1766 LUTs
|> -k 7 crash back to OS
|> -k 8 crash back to OS
|> 
|> I'm still running 3.3.08i.

Hm, can you try to switch off DC's LUT-mapping? For the 4000-series it was
something like 
"set_attribute find(design,"*") "xnfout_write_map_symbols" -type boolean FALSE".

Or maybe I'm mixing that up with fpga_compiler... so long ago...
-- 
         Georg Acher, acher@in.tum.de         
         http://www.in.tum.de/~acher/
          "Oh no, not again !" The bowl of petunias          

Article: 40215
Subject: Re: Xilinx Virtex Family die photos...
From: "Speedy" <speedracer67@yahoo.invalid>
Date: Sat, 02 Mar 2002 03:10:28 GMT
Links: << >>  << T >>  << A >>
Have you tried google image search?
Type in "xilinx virtex", click on the second image "[ More results from
www.chipworks.com ] ", and there is a Virtex II.  Higher res would be nice,
maybe you already found this one.

Ryan


"Nicholas Weaver" <nweaver@CSUA.Berkeley.EDU> wrote in message
news:a5ohvj$1drt$1@agate.berkeley.edu...
> Does anyone have a nice hi-res photo of a Xilinx Virtex CLB or general
> die?  Google has failed me.
>
> thanks.
>
> --
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu



Article: 40216
Subject: Re: Altera Excalibur
From: "Peter Ormsby" <faepete.deletethis@mediaone.net>
Date: Sat, 02 Mar 2002 03:45:06 GMT
Links: << >>  << T >>  << A >>
jerry1111 <jerry1111@wp.pl> wrote in message
news:a5oj6f$mjh$1@news.tpi.pl...
> Hello,
>
> I want to buy Altera's softcore uP.
> Which one: Nios-based or Arm-based?

Here's the scoop on Altera's Excalibur...

Nios is a soft-core processor that can be implemented in any SRAM-based
Altera device SINCE the Flex 6000 devices (since the Flex 6000 devices don't
have any RAM blocks, it can't implement the required processor registers).
That means that a Nios processor can be targetted at Acex 1K, Flex 10K, Apex
20K/E/C, Apex II, Mercury, Stratix, and any new family introduced in the
future.  Once you've purchased the Nios development kit, you can use Nios in
any number of products you create in any Altera device you select with no
royalties or additional costs.

The Excalibur ARM device is a hard processor core.  The devices are Apex
20KE parts married to a processor "stripe" that contains the ARM core (plus
cache memories), an interupt controller, a watchdog timer, an SDRAM
controller, timers, a UART, an expansion bus interface (for external SRAM,
Flash, etc), an ARM debug trace module, and a bunch of SRAM and dual-port
SRAM (quantity varies with device size but ranges from 32KBytes SRAM and 16
KBytes of dual-port up to 256Kbytes SRAM and 128KBytes of dual-port).  All
of these peripherals are HARD IP created in dedicated silicon.   This allows
the ARM processor to be alive at power-up before the FPGA part of the device
is configured.  The ARM stripe has the capability of controlling the
configuration of the FPGA, if you desire.  Since the ARM processor is a
standard ARM922T core, all third-party ARM development tools (compilers.
linkers, etc) will work with this device.

Note that the two Excalibur solutiuons are not exclusive of each other - you
can easily instantiate one or more Nios cores in the programmable portion of
the Excalibur ARM devices.

In general, the Nios processor is targetted to solutions where you might use
a microcontroller or an "embedded" processor while the ARM is the higher
performance option.  Note that due to Nios's ability to create custom
instructions and to support multiple simultaneous bus masters (for
concurrent DMA, etc), you can get performance far beyond what one might
otherwise expect from an 50-100 MHz processor.

-Pete-



Article: 40217
Subject: Re: Xilinx Virtex Family die photos...
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Sat, 2 Mar 2002 04:20:51 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <EoXf8.1279$en5.9349@typhoon.sonic.net>,
Speedy <speedracer67@yahoo.invalid> wrote:
>Have you tried google image search?
>Type in "xilinx virtex", click on the second image "[ More results from
>www.chipworks.com ] ", and there is a Virtex II.  Higher res would be nice,
>maybe you already found this one.

Thanks.  The chipworks one wasn't very good, but I got some hits on
xilinx's japanese press website.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 40218
Subject: Re: stuck in state in Spartan-II!
From: Phil Hays <spampostmaster@attbi.com.com>
Date: Sat, 02 Mar 2002 04:34:30 GMT
Links: << >>  << T >>  << A >>
Ken Mac wrote:
> 
> Phil,
> 
> Forgot to mention that the DAC is fed the 425kHz clock via a pin of my
> Spartan-II.
> 
> The DAC uses the negative edges of the 425kHz clock to take data from
> process C.
> 
> Process C uses the positive edges of the 425kHz clock to place data on the
> serial data pin for the DAC and the negative edges then drive the DAC.
> 
> My DAC output now seems to be irregular - what signal should I use to clock
> my DAC now?

I'm not quite sure what you mean by irregular.  If you used a version of 425 kHz
that had been synchronized to the 33 MHz clock, there would be noticable jitter
in the timing of the DAC output.  Do you mean jitter in the timing of new data
output from the DAC?

Hope this helps.


-- 
Phil Hays

Article: 40219
Subject: Re: Altera Excalibur
From: "jerry1111" <jerry1111@wp.pl>
Date: Sat, 2 Mar 2002 12:19:14 +0100
Links: << >>  << T >>  << A >>
> Note that the two Excalibur solutiuons are not exclusive of each other - you
> can easily instantiate one or more Nios cores in the programmable portion of
> the Excalibur ARM devices.

OK. Whan i buy Nios devel kit, will there be support
for ARMs also? There are two devel kits on Altera website
(one for Nios and one for Arm), so suppose I don't get
ARM support in Nios kit. Right? I must buy some module for
Quartus in order to use Arms?
A assume that development boards differ (one is pure fpga, and second
if an fpga with Arm structure), but is software in both kits identical, or not?

TIA

jerry



Article: 40220
Subject: Re: Altera Excalibur
From: "Victor Schutte" <victors@mweb.co.za>
Date: Sat, 2 Mar 2002 16:54:54 +0200
Links: << >>  << T >>  << A >>
Jerry, look at this in a different way. NIOS provides you with a complete IP
CPU solution. You can migrate this design between different Altera FPGAs,
have more than 1 CPU on the FPGA and eventually even make an ASIC from the
design. You are currently limited by speed (technology and implentation) to
about 60MHz to 80MHz.

The ARM option is a hardwired CPU on the FPGA running at 166MHz(?). If you
suddenly need 2 or more ARM CPUs you will need more ICs. With NIOS you only
upgrade to a bigger device and include another one.

I would suggest that you go for the NIOS option first (only $995). With it
you will everything you need.

You will probably find that it might be cheaper to buy a standalone MIPS or
ARM CPU than to have it included on a FPGA (please correct me if I am
wrong). The other day a sales rep. from Avnet gave me a quote on ridiculous
low prices on the new Hitachi 32bit CPUs. Even the compiler was something
like only $400.

I use NIOS because I can get my CPU, 4 serial ports, 67 I/O lines, timer,
multiplier and  WDT into one FPGA. My hardware stays the same while NIOS
allows me to make tweeks to the hardware. Plus, the free compiler (you can
redistribute it for free) makes it all the more better.

Cost wise it might seem still a bit expensive. My entry level board (please
email for more specs) currently sells for about $350 (small quantities).

Victor



"jerry1111" <jerry1111@wp.pl> wrote in message
news:a5oj6f$mjh$1@news.tpi.pl...
> Hello,
>
> I want to buy Altera's softcore uP.
> Which one: Nios-based or Arm-based?
> Any suggestions?
> Before spending money for development tools I'd like
> to know the good and bad news for it.
>
> Is it possible to move from Nios to Arm-based without
> spending lot of money for Arm option (already having
> Nios purchased)?
>
> Thanks
>
> jerry
>
>



Article: 40221
Subject: Re: Altera Excalibur
From: "jerry1111" <jerry1111@wp.pl>
Date: Sat, 2 Mar 2002 16:14:25 +0100
Links: << >>  << T >>  << A >>
> Jerry, look at this in a different way. NIOS provides you with a complete IP
> CPU solution. You can migrate this design between different Altera FPGAs,
> have more than 1 CPU on the FPGA and eventually even make an ASIC from the
> design. You are currently limited by speed (technology and implentation) to
> about 60MHz to 80MHz.

Yeah, but sometimes I will need 1 FAST cpu (let's say hardwired ARM) and
2 or 3 slower Nioses on the same chip. I prefer writing 'parralel' code
for 2 or 4 smaller uP rather than for one big uP.

> You will probably find that it might be cheaper to buy a standalone MIPS or
> ARM CPU than to have it included on a FPGA (please correct me if I am
> wrong). The other day a sales rep. from Avnet gave me a quote on ridiculous
> low prices on the new Hitachi 32bit CPUs. Even the compiler was something
> like only $400.

Are any GNU C compilers for ARM available? I didn't find them.

jerry



Article: 40222
Subject: Re: share two months salary with you if you have job information
From: Tom <tomcip@concentric.net>
Date: 02 Mar 2002 16:04:40 GMT
Links: << >>  << T >>  << A >>


Ryan Henderson wrote:

> Wow, I hope things really haven't gotten this bad....

Yes, they have!

I applaud the original poster and his ambition. However, relocating for
a tech position is generally a bad idea. You could be fired/laid-off
while you are in the moving van with all of your stuff heading towards
your new job and nobody would even tell you until you showed up for
work. In fact, the person that hired you in the first place may have
been canned by then. I'll bet you think I'm joking here.

Hey, what is the new Silicon Valley status symbol? Employment.

Tom




>
>
> -Ryan


Article: 40223
Subject: Re: share two months salary with you if you have job information
From: "Lewin A.R.W. Edwards \(Despammed\)" <spam@larwe.com>
Date: Sat, 02 Mar 2002 16:38:48 GMT
Links: << >>  << T >>  << A >>
> I applaud the original poster and his ambition. However, relocating for
> a tech position is generally a bad idea. You could be fired/laid-off
> while you are in the moving van with all of your stuff heading towards

This is true of any job. Part of making a sensible decision about whether
the move is worth it involves studying the company, the division you'd be
working in and other factors and determining if the position you're moving
into will have a long-term existence. Relocating for a tech position is no
more/less a bad idea than relocating for /any/ position. And luck is a big
part of it.

--
-- Lewin A.R.W. Edwards
Replace spam with larwe when emailing!
For-hire : http://www.zws.com/
Personal: http://www.larwe.com/
Day job: http://www.digi-frame.com/



Article: 40224
Subject: Embedding counting in an FSM.
From: "Joey Nelson" <highfreq@micron.net>
Date: Sat, 2 Mar 2002 10:27:34 -0800
Links: << >>  << T >>  << A >>
I'm wondering if it is advisable to embed counting logic in an FSM, say for
a delay.

What I have been doing thus far is having an uber-module with the fsm logic
in one sub-module and the delay in a down-counter sub-module.  Then the FSM
loads the counter with the delay count on a Meally output when transiting to
the delay state, it then exits the delay state upon the counter reaching
zero.

I think it would make the design easier to follow if the counting were
simply handled in the FSM with assignments and decrements.  Is this a
reasonable thing to do?  How well do synthesis tools handle this?  Can they
still infer the counter?  If I have multiple such delays in one FSM, will
the tools recognize the delays are mutually exclusive and only synthesize a
single shared counter?

If any one has any insight it would be much appreciated.

Joey





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