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 40225

Article: 40225
Subject: Re: share two months salary with you if you have job information
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Sat, 02 Mar 2002 18:41:51 GMT
Links: << >>  << T >>  << A >>
"Ryan Henderson" <hendersr@oit.edu> wrote:
> Wow, I hope things really haven't gotten this bad....
>
> -Ryan

Ryan,
   Apparently they have and are.  The difference between now and the past is
that we have this avenue called the Internet to use as a resource.  Now we
get to see many things that we didn't get to see in the past.  I saw a down
cycle in the early 1990s that was just as bad as this one, but we didn't get
to see how hard up we were back then unless you knew us personally.
   I post in this and other newsgroups semi-regularly, and because I own a
business, my posts draw attention from various engineers, mostly university
students, looking for jobs.  I can't say that I blame them, but right now
I'm looking for business, too!  I am very confident, though, that this
situation will turn around soon.
   Everybody, save your nickels, dimes, euros, etc.,  and let's ride out
this roller coaster dip!
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL  USA



Article: 40226
Subject: Re: Altera Excalibur
From: Muzaffer Kal <muzaffer@dspia.com>
Date: Sat, 02 Mar 2002 18:46:49 GMT
Links: << >>  << T >>  << A >>
On Sat, 2 Mar 2002 16:14:25 +0100, "jerry1111" <jerry1111@wp.pl>
wrote:

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

http://www.armlinux.org/docs/toolchain/
http://www.lart.tudelft.nl/lartware/compile-tools/


Muzaffer Kal

http://www.dspia.com
ASIC/FPGA design/verification consulting specializing in DSP algorithm implementations

Article: 40227
Subject: turnaround cycle?
From: v_ralev@yahoo.com (Vladimir Ralev)
Date: 2 Mar 2002 11:31:49 -0800
Links: << >>  << T >>  << A >>
Hello all!

I am reading the pci specs and found a term 'turnaround cycle'. What is that?

Thank you!

Article: 40228
Subject: Re: What FPGA to use?
From: Ray Andraka <ray@andraka.com>
Date: Sat, 02 Mar 2002 20:01:52 GMT
Links: << >>  << T >>  << A >>
The Xilinx VirtexII is the only device that has them that you can buy
today.  Altera announced its Stratix line a little more than a week ago,
which also has dedicated multipliers.  You'll have to talk to a distributor
to fins out when you can get one.

That said, I am assuming you are talking about audio mixing.  If that is the
case, you can get into a smaller, cheaper device by working with bit serial
arithmetic for the mixing.  In that case, the multiplier is little more than
an adder.  See the multiplier page on my website (when it comes back
up...seems the ball got dropped in transferring the domain name to the new
ISP so it may be a day or so before you can get to the website).

Remco Poelstra wrote:

> Hi,
>
> I want to build a digital mixing console, using an FPGA for the signal
> processing, so I can do it (almost) all in parrallel. I need a lot of
> multipliers for that task. What's the best FPGA to do that? I heard that
> there are FPGA's with build-in multipliers, so I can spend the gates at
> other things, is this true? Which FPGA's have build-in multipliers? Btw,
> I also need a lot of input pins...
>
> Thanks for any advice,
>
> Remco Poelstra

--
--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: 40229
Subject: What FPGA to use?
From: Remco Poelstra <rjpoelstra@home.nl>
Date: Sat, 02 Mar 2002 21:26:17 +0100
Links: << >>  << T >>  << A >>
Hi,

I want to build a digital mixing console, using an FPGA for the signal 
processing, so I can do it (almost) all in parrallel. I need a lot of 
multipliers for that task. What's the best FPGA to do that? I heard that 
there are FPGA's with build-in multipliers, so I can spend the gates at 
other things, is this true? Which FPGA's have build-in multipliers? Btw, 
I also need a lot of input pins...

Thanks for any advice,

Remco Poelstra


Article: 40230
Subject: Re: Embedding counting in an FSM.
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Sat, 02 Mar 2002 13:33:59 -0800
Links: << >>  << T >>  << A >>
Joey Nelson wrote:
> 
> I'm wondering if it is advisable to embed counting logic in an FSM, say for
> a delay.

You can embed counting logic in any clocked process.

> 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.  

I agree.

> Is this a reasonable thing to do?  

If it is easier for you to understand, yes.
The most likely person to be modifying 
this code a year from now is you.

Some designers like to think in schematics
and code in counter sized modules. 

Others might see a single process that 
checks inputs and local (state) variables,
and then updates output signals and local variables
at every rising clock edge.

Most are probably somewhere between
these extremes.

> How well do synthesis tools handle this?  

Just fine. Things like:

count := count - 1;

in a clocked process is bread and butter 
to most HDL designers.

> 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?

This is the reason you write a testbench and simulate your code.
The synthesizer doesn't know what you are thinking, but it will
generate a netlist that simulates the same as your code.

For an example of inferring a counter and shifter in
a single process, see last week's thread

"Re: coding style of a FSM"

on comp.lang.vhdl

   -- Mike Treseler

Article: 40231
Subject: Re: turnaround cycle?
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Sat, 02 Mar 2002 16:03:56 -0600
Links: << >>  << T >>  << A >>
A turnaround cycle means that an agent driving the PCI bus a clock cycle
earlier turns off the driving of the bus, and at the next clock cycle or
at later time, another agent can start driving the bus.
This turnaround cycle is needed to ensure that contention of driving the
bus won't happen.
For example, during a read cycle, a turnaround cycle for AD[31:0] occurs
a clock cycle after an address phase.
For signals like IRDY#, TRDY#, DEVSEL#, and STOP#, a turnaround cycle
occurs during an address phase when a Fast Back-to-Back transfer is
happening, and when a Fast Back-to-Back transfer is not happening, a
turnaround cycle occurs during an idle cycle (An idle cycle is, FRAME# =
'H' and IRDY# = 'H'.).
However, for other signals like AD[31:0], C/BE#[3:0], and FRAME#, a
turnaround cycle happens during an idle cycle.
PAR's turnaround cycle occurs one cycle later than the turnaround cycle
of AD[31:0] and C/BE#[3:0].




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




Vladimir Ralev wrote:
> 
> Hello all!
> 
> I am reading the pci specs and found a term 'turnaround cycle'. What is that?
> 
> Thank you!

Article: 40232
Subject: Re: Altera Excalibur
From: Petter Gustad <newsmailcomp1@gustad.com>
Date: Sat, 02 Mar 2002 22:04:18 GMT
Links: << >>  << T >>  << A >>
"Victor Schutte" <victors@mweb.co.za> writes:

> 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,

Can you run Linux on the NIOS? Does it have a MMU? What would be the
cost of migrating to an ASIC in terms of license fees?

Petter
-- 
________________________________________________________________________
Petter Gustad   8'h2B | (~8'h2B) - Hamlet in Verilog   http://gustad.com

Article: 40233
Subject: Re: What FPGA to use?
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Sat, 02 Mar 2002 14:07:30 -0800
Links: << >>  << T >>  << A >>
Remco Poelstra wrote:

> Which FPGA's have build-in multipliers? 

Xilinx virtex2 is in stock.

Altera stratix was just announced.
"The first device, the EP1S25, will be sampling 
in the second quarter with volume
pricing starting at $125 in 2003."

 -- Mike Treseler

Article: 40234
Subject: Re: What FPGA to use?
From: "Paul" <nospam@nospamplease.com>
Date: Sat, 2 Mar 2002 22:18:35 -0000
Links: << >>  << T >>  << A >>
As an Altera devotee, I would strongly suggest you take a look at Xilinx
parts for now. Right software,, right silicon, and right support from some
expert 'volunteers' here and elsewhere.

People like Ray Andraka and Peter Alfke make a huge difference.

Paul

"Mike Treseler" <mike.treseler@flukenetworks.com> wrote in message
news:3C814D22.C0440767@flukenetworks.com...
> Remco Poelstra wrote:
>
> > Which FPGA's have build-in multipliers?
>
> Xilinx virtex2 is in stock.
>
> Altera stratix was just announced.
> "The first device, the EP1S25, will be sampling
> in the second quarter with volume
> pricing starting at $125 in 2003."
>
>  -- Mike Treseler



Article: 40235
Subject: Re: Altera Excalibur
From: "Peter Ormsby" <faepete.deletethis@mediaone.net>
Date: Sun, 03 Mar 2002 02:47:52 GMT
Links: << >>  << T >>  << A >>
Petter Gustad <newsmailcomp1@gustad.com> wrote in message
news:87r8n2slz0.fsf@filestore.home.gustad.com...
> Can you run Linux on the NIOS? Does it have a MMU? What would be the
> cost of migrating to an ASIC in terms of license fees?
>
> Petter

Petter,

Micronix has a uC Linux port for Nios.  Like all Linux versions, I suppose
the source code is freely available from Micronix somewhere, but you can buy
a "supported" version though Altera's Linux Development Kit.  The kit is an
add-on to the Nios dev. board and includes the Linux software, an SODIMM
card with a bunch of SRAM and Flash on board, an attachement which adds a
real-time clock and an IDE/Compact Flash interface, and a 10baseT ethernet
MAC/PHY connector.  It also comes with a web-server application as an
example design.

uC Linux is a version of Linux that was made specifically for embedded
systems (read: no MMU required).  As far as migrating to an ASIC, Altera has
said that they will license the core for an ASIC "at an additional cost".  I
honestly have no idea what sort of cost this would be (contact an Altera
salescritter for this sort of info).

As long as I'm posting, I'll also respond to Jerry1111's last post about the
difference between the Excalibur ARM development Kit and the Excalibur Nios
development kit:

Think of the Excalibur ARM development kit as an evaluation board with some
support software included (The ARM Developers Suite (Lite), reference
designs, utilities, etc).  The Nios development kit is a package of
Intellectual Property for the Nios CPU and a bunch of peripherals (UART,
timers, SPI, DMA, I/O, etc) with an included evaluation board, a license for
tools, a programming cable, and a bunch of documentation.

If you were to create a system with an Excalibur ARM device containing
several Nios processors in the programmable section, you'd have to get the
Nios kit (for the IP license), but you wouldn't need the Excalbur ARM
development kit unless you didn't want to design your own board to hold the
device.

-Pete-



Article: 40236
Subject: Xilinx WebPack Simulation
From: alw@al-williams.com (Al Williams)
Date: 2 Mar 2002 22:55:28 -0800
Links: << >>  << T >>  << A >>
I seem to be stumped. 

Using the Xilinx WebPack to do some XC9500 work. Everything works
great including the actual hardware. When I do a behaviorial
simulation I put a little verilog block in that pulses PRLD, GTS, GR,
and GSR -- I know I don't need all of them, but I just use on block
for every case. That works fine.

However, when I try to simulate post fit without the simulation block
(which won't work in synthesis) I can't get the simulation to work. I
manually set the PRLD and other lines. It will look like it works
until suddenly a T flip flop should flip and instead goes to x and
stays there. Again, with the little sim block it works great. And it
works great in the real hardware.

Any tips?

Thanks in advance.

Article: 40237
Subject: Xilinx MXE 5.5 v.s. ModelSim PE for Xilinx Spartan II only
From: yunhsianghsu@aol.com (Yunhsianghsu)
Date: 03 Mar 2002 08:32:28 GMT
Links: << >>  << T >>  << A >>
Dear All,

I am using Xilinx Spartan II only in my projects. I have ModelSIm PE to be my
simlulator. As I known, Xilinx release a new simulator, MXE 5.5. Comparing
those two proces, MXE seems much cheaper.

If I am going to use Spartan II only, is it better to purchase MXE ?

Please advise, thanks.

Kenny


Article: 40238
Subject: Re: turnaround cycle?
From: v_ralev@yahoo.com (Vladimir Ralev)
Date: 3 Mar 2002 01:42:59 -0800
Links: << >>  << T >>  << A >>
Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote in message news:<a5rhml$5e2$1@newsreader.mailgate.org>...
> A turnaround cycle means that an agent driving the PCI bus a clock cycle
> earlier turns off the driving of the bus, and at the next clock cycle or
> at later time, another agent can start driving the bus.
> This turnaround cycle is needed to ensure that contention of driving the
> bus won't happen.
> For example, during a read cycle, a turnaround cycle for AD[31:0] occurs
> a clock cycle after an address phase.

There is still something unclear:
If I sample the data on AD[31:0] during a turnaround cycle after the
address phase(the example u mentioned about), what would i get? The
last state?

Thanks

Article: 40239
Subject: Re: Rising and falling edge of a clk
From: "H.L" <alphaboran@yahoo.com>
Date: Sun, 3 Mar 2002 13:41:31 +0200
Links: << >>  << T >>  << A >>
Hi Ray,
I have seen these tips written by you many times in this group. I have them
always as a guide but I want to see if I understand them right. Please
correct me where I am wrong:

1) The need for additional registers in DATA_IN and ADDR signals.
In BRAMs the EN and WE signals  have long set-up times thats why we need to
register the data_in and addr of the BRAM, in this way the addr and data_in
signals have a clock period delay.As EN,WE reach the BRAM 1 clock period
earlier (at 155MHz  clock speed that means about 6 ns) the setup-time for
these signals is not violated resulting BRAM to be in the operation mode we
wish (read or write) the moment addr and data_in arrive.
2) The need for floorplanning
Xilinx software tool maybe has put the additional registers far from the
BRAMs, if this is the case we must manual place them near the BRAM to
decrease the propagation delay of the signals.
3) Tying the WE,EN inputs and contol access through the address when working
at high speeds.
Do you mean to keep WE,EN high all the time and when we wish not to use the
BRAMs to write dummy data in some (or just one) specified addresses (or
address) reserved for this reason?

Also I have another one question about BRAMs, Xilinx says that BRAMs' DATA
OUT are already registered. In Xilinx Floorplanner I believe this register
is "inside" the BLKRAM box so no manual floorplanning for the output is
needed. You need to manual floorplan (in the same way you do for the inputs)
only if you choose to add an additional output register, correct?

I really appreciate your help.

Best Regards,
Harris

"Ray Andraka" <ray@andraka.com> wrote in message
news:3C7FD73D.F6A3109A@andraka.com...
> VirtexE BRAMs can be written at 155MHz in any speed grade.  To do so, you
will
> likely have to put registers near to and with no logic between them and
the
> BRAMs.  Watch the loading too, routing to more than 1 BRAM for each
register may
> cause you some heartburn.  At higher speeds, you probably should also
consider
> tying the WE, and ENA inputs active and controlling your access through
the
> address registers instead.  You'll also need to floorplan the registers to
make
> sure they are located physically close to the BRAMs.
>
> "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.
> > >
>
> --
> --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: 40240
Subject: Re: Rising and falling edge of a clk
From: "H.L" <alphaboran@yahoo.com>
Date: Sun, 3 Mar 2002 13:41:49 +0200
Links: << >>  << T >>  << A >>
Hi Peter,
I didnt know that this thing I did is called "double-buffering" so thank you
:-)
I use a Virtex-E FPGA for my design. I dont know the thing that you
mentioned about reading at different width, I will take a look at Virtex-II
BRAM datasheet to learn more.

Best Regards,
Harris


"Peter Alfke" <peter.alfke@xilinx.com> wrote in message
news:3C7FE5D2.867309EA@xilinx.com...
> 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: 40241
Subject: Re: Altera Excalibur
From: "jerry1111" <jerry1111@wp.pl>
Date: Sun, 3 Mar 2002 13:19:35 +0100
Links: << >>  << T >>  << A >>
> Micronix has a uC Linux port for Nios.  Like all Linux versions, I suppose
> the source code is freely available from Micronix somewhere, but you can buy

Source is not freely available (you got src when you buy uCLinux).
At least I didn't find it in microtronix website.

> uC Linux is a version of Linux that was made specifically for embedded
> systems (read: no MMU required).

I'm thinking about stability of this version. If one process goes
wrong it can crash all processes (no MMU => no SIGSEGV => we don't even
know about destroying other processes' data/program space).

> Think of the Excalibur ARM development kit as an evaluation board with some

So, if I have my own board with Atera's Arm-filled fpga, the only thing
I need is description file  of FPGA which tells Quartus where are ARM's pins
inside structure? And then I can use 3rd party software tools?

And question about embedded linux. Which one to choose?
For Nios (costs money) or some free versioins for ARM?
Have someone used them?


jerry



Article: 40242
Subject: Re: turnaround cycle?
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sun, 03 Mar 2002 12:42:46 +0000
Links: << >>  << T >>  << A >>


Vladimir Ralev wrote:

> Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote in message news:<a5rhml$5e2$1@newsreader.mailgate.org>...
> > A turnaround cycle means that an agent driving the PCI bus a clock cycle
> > earlier turns off the driving of the bus, and at the next clock cycle or
> > at later time, another agent can start driving the bus.
> > This turnaround cycle is needed to ensure that contention of driving the
> > bus won't happen.
> > For example, during a read cycle, a turnaround cycle for AD[31:0] occurs
> > a clock cycle after an address phase.
>
> There is still something unclear:
> If I sample the data on AD[31:0] during a turnaround cycle after the
> address phase(the example u mentioned about), what would i get? The
> last state?
>
> Thanks

Its possible to argue that a CMOS bus would hold the last value driven onto it for at least one 33MHz clock however its equally
possible that the clock edge used to float the drivers also changes the value in the initiator's output data registers so you'll get
a race. Therefore ...

... You must assume you'll  get the second most infamous digital object of them all - the great, system eating, "UNDEFINED". As the
Bhuddists say: ``Pass over it, but build no house on it'' :-).

The most infamous is of course metastability but one could argue that its an analogue phenomenon.


Article: 40243
Subject: Re: Xilinx WebPack Simulation
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sun, 03 Mar 2002 12:57:59 +0000
Links: << >>  << T >>  << A >>


Al Williams wrote:

> I seem to be stumped.
>
> Using the Xilinx WebPack to do some XC9500 work. Everything works
> great including the actual hardware. When I do a behaviorial
> simulation I put a little verilog block in that pulses PRLD, GTS, GR,
> and GSR -- I know I don't need all of them, but I just use on block
> for every case. That works fine.
>
> However, when I try to simulate post fit without the simulation block
> (which won't work in synthesis) I can't get the simulation to work. I
> manually set the PRLD and other lines. It will look like it works
> until suddenly a T flip flop should flip and instead goes to x and
> stays there. Again, with the little sim block it works great. And it
> works great in the real hardware.
>
> Any tips?
>
> Thanks in advance.

If you are using the post-fit net list then you have moved into the realm
of timing simulation and so you may be getting setup/hold violations on
your T-FF. The simprim models used for this simulation will set the
output to `X' when such a violation occurs. This is esp. likely if the FF
is sampling an asynchronous input. You could try either:

o Slowing down the clock, or

o If you're using the ModelSim starter edition that comes with WebPACK
try setting
+no_notifier on the vsim command line or even +notimingchecks. Make sure,
though,  that +no_tchk_msg is *not* set so that you can see any timing
violations even if they don't set the output to `X'.


Article: 40244
Subject: thank you friends
From: "Daniel Yap" <daniu_yap@hotmail.com>
Date: Sun, 3 Mar 2002 22:22:56 +0800
Links: << >>  << T >>  << A >>
Hi,

Finally I managed to finish my final year project concern FIR digital filter
using VHDL.

I want to thank you to all the experts here, especially Ray,Cohen and
others. Thank you for the advices.

This is a very good group and I recommend to anyone who needs advice in VHDL
and FPGAs.

Regards,
Daniel



Article: 40245
Subject: Re: Rising and falling edge of a clk
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 03 Mar 2002 15:48:47 GMT
Links: << >>  << T >>  << A >>

"H.L" wrote

> I use a Virtex-E FPGA for my design. I dont know the thing that you
> mentioned about reading at different width, I will take a look at Virtex-II
> BRAM datasheet to learn more.

All Xilinx BlockRAMs are dual-ported. Each port has its own address data, WE,
EN, and clock. The only thing the two ports have in common is the storage
array.
But each port's "aspect ratio" can also be independently configured. So one
port can have many parallel data bits and fewer address bits, while the other
port has narrower data and more adresses. There are no constraints. That
sometimes eliminates the need for a P/S or S/P converter.

Regarding your question about an internal output register:
There is no extra output register, but as the data sheet says: "The state of
the (data ) outputs will not change until the port excutes another read or
write operation". If you feel like it, you can consider it an output register,
but it really is just looking at the internal data array, using its latched
adress.

Peter Alfke, Xilinx Applications



Article: 40246
Subject: Re: Creation of FPGA tips and tricks forum - help required
From: Christopher.Saunter@durham.ac.uk (Christopher Saunter)
Date: Sun, 3 Mar 2002 16:05:52 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hi Paul,

	When getting into new things in the past, I have found 'Wiki's to
be very usefull, -when- they are well maintained.  (the father of them all
is http://c2.com/cgi/wiki) 

Being new to programmable logic, I have found both this newsgroup and the
FAQ tremendous resources (with a big thanks to all who contribute.)  I
have been tempted to try setting up a wiki with a slant towards DSP-FPGA
design, but it's all a matter of time and knowledge...

I would be intrested in helping with such a project, as it would be
interesting to see how such a system might complement the ng/faq, but I
guess it's really a question of weather others would be interested
(....  :-)

It'd be nice to find somewhere where the more 'far out' FPGA bassed voodoo
is discussed (like projects where designs are bred 'genetically' resulting
in very odd designs that get the job done very oddly.  Can't find the
references at the moment... - admited such things can't do much at the
moment, and probably won't mean much comercially for some time, bit I find
that sort of thing fascinating)

Anyway, just my two pence.

Chris Saunter

Paul (nospam@nospamplease.com) wrote:
: Having come back to logic design after a 5 year break, I had a bit of a
: culture-shock with the myriad of different tools and their inherent
: strengths and weaknesses.

: I'm hoping to help make it a bit easier for others and expand my current
: limited understanding by creating a set of forums for discussion.

: My aim in creating the forums was:

: 1) Provide a forum for discussion of various programmable logic tools and
: how best to use them.

: 2) Provide a place to store tips and techniques used by programmable logic
: designers.

: 3) Complement the discussions on the main programmable logic newsgroups and
: perhaps go into more specific detail and provide more tutorial information
: to supplement the newsgroup information.

: 4) Provide an edited summary of valuable discussions on the newsgroups.

: At present I'd appreciate any comment and assistance in starting up the
: process.

: http://pub64.ezboard.com/bfpgatipsandtricks


: Because the forums are new I've focussed on Altera-based tools, but over the
: coming weeks if there is sufficient interest I'll attempt to extend them to
: other device toolsets.

: I should point out that there is little useful content on the forums as yet,
: which is where your assistance would be invaluable.

: You will need to register a user name, email  and some details to post
: (viewing doesn't require this). How accurately you want to do this is
: entirely up to you.

: If you need to contact me, try pauljnospambaxter@hotnospammail.com without
: the nospam bits.

: Feedback appreciated.








Article: 40247
Subject: Re: Rising and falling edge of a clk
From: Ray Andraka <ray@andraka.com>
Date: Sun, 03 Mar 2002 16:26:17 GMT
Links: << >>  << T >>  << A >>


"H.L" wrote:

> Hi Ray,
> I have seen these tips written by you many times in this group. I have them
> always as a guide but I want to see if I understand them right. Please
> correct me where I am wrong:
>
> 1) The need for additional registers in DATA_IN and ADDR signals.
> In BRAMs the EN and WE signals  have long set-up times thats why we need to
> register the data_in and addr of the BRAM, in this way the addr and data_in
> signals have a clock period delay.As EN,WE reach the BRAM 1 clock period
> earlier (at 155MHz  clock speed that means about 6 ns) the setup-time for
> these signals is not violated resulting BRAM to be in the operation mode we
> wish (read or write) the moment addr and data_in arrive.

If you look at the data sheet, there are fairly long set-up times on all the
BRAM inputs.  Routing to the BRAMs also adds to the delay, as does any
combinatorial logic on these inputs.  The idea of putting registers on the
inputs (which includes the EN and WE inputs) is to minimize the amount of delay
added externally to these signals.  Your understanding is a bit incorrect, as
what you are suggesting is delaying signals to allow a long combinatorial
delay.  That is dangerous, because there is no guarantee on the minimum delay.
Instead, what I am suggesting is to remove as much of the delay as possible
between the registers driving the BRAM inputs and the BRAM inputs, which meahs
avoiding combinatorial logic on these paths, minimizing the fanout of these
signals, and physically locating the registers close to the BRAMs.

>
> 2) The need for floorplanning
> Xilinx software tool maybe has put the additional registers far from the
> BRAMs, if this is the case we must manual place them near the BRAM to
> decrease the propagation delay of the signals.

That is correct.  Routing in FPGAs is not just wire, it also consists of
switches which add to the propagation delay of signals on the connections
between logic.  Manually placing the registers near the BRAM helps to minimize
the added delay.

>
> 3) Tying the WE,EN inputs and contol access through the address when working
> at high speeds.
> Do you mean to keep WE,EN high all the time and when we wish not to use the
> BRAMs to write dummy data in some (or just one) specified addresses (or
> address) reserved for this reason?

That is correct.  The set up times for EN and WE are nearly twice the set-up
times for address and data, so if we can eliminate these from the equation we
can run at a higher clock rate.  They can be eliminated by always writing, but
directing the writes of invalid data to locations where it does not affect the
operation of the design.  In the case of FIFOs, you can just park the write
address until you have a valid write, since you are presumably not reading that
data until it is valid.

>
>
> Also I have another one question about BRAMs, Xilinx says that BRAMs' DATA
> OUT are already registered. In Xilinx Floorplanner I believe this register
> is "inside" the BLKRAM box so no manual floorplanning for the output is
> needed. You need to manual floorplan (in the same way you do for the inputs)
> only if you choose to add an additional output register, correct?

That is correct, the BRAM acts as though it is registered, although I believe
the actual implementation has the register on the address, not on the memroy
outputs.  In any event, the clock to out time is long compared to that of the
CLB flip-flops.  The system clock rate can be increased by putting an additional
register on the BRAM data outputs and placing that register physically close to
the BRAM (that register should have no combinatorial logic in front of it).

>
>
> I really appreciate your help.
>
> Best Regards,
> Harris
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3C7FD73D.F6A3109A@andraka.com...
> > VirtexE BRAMs can be written at 155MHz in any speed grade.  To do so, you
> will
> > likely have to put registers near to and with no logic between them and
> the
> > BRAMs.  Watch the loading too, routing to more than 1 BRAM for each
> register may
> > cause you some heartburn.  At higher speeds, you probably should also
> consider
> > tying the WE, and ENA inputs active and controlling your access through
> the
> > address registers instead.  You'll also need to floorplan the registers to
> make
> > sure they are located physically close to the BRAMs.
> >
> > "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.
> > > >
> >
> > --
> > --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
> >
> >

--
--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: 40248
Subject: Re: Embedding counting in an FSM.
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 03 Mar 2002 12:25:19 -0500
Links: << >>  << T >>  << A >>
Joey Nelson wrote:
> 
> 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

I don't think it will make much difference either way, except for fast
designs where you need to control each state variable and output to meet
timing.  Then it will likely be easier to control your result if the
counter is separate.  I doubt that the synthesizer can figure out that
several counters can be optimized into one, but it won't see your delay
states as a counter.  They will just be more states in your FSM and the
entire machine will be optimized together.  As long as you don't try to
use one hot encoding, it will do a reasonable job of it.  The only
question is, will the added counter states make the FSM too complex to
run at your required speed?  Keeping the counter separate will allow you
to make the FSM simpler and easier to meet timing.  

-- 

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: 40249
Subject: Re: Altera's new family Stratix
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 03 Mar 2002 13:00:21 -0500
Links: << >>  << T >>  << A >>
Magnus Homann wrote:
> 
> Rick,
> 
> http://www.xilinx.com/ise/marketing/index.htm
> 
> (Just ignore that it says 'marketing' in the link...)
> 
> Homann
> --
> Magnus Homann, M.Sc. CS & E
> d0asta@dtek.chalmers.se

It can be ignored, but you will notice that there is no real information
on these pages.  But it is a start.  Too bad that I am using Spartan IIE
and this is only available for VirtexII and E.  We will see if they come
out with updates for Spartan lines.  


-- 

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



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