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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

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 154250

Article: 154250
Subject: Re: Looking for an extremely cheap FPGA board (in quantity, academic use)
From: Mark Brehob <brehob@gmail.com>
Date: Sun, 16 Sep 2012 08:52:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 13, 3:03=A0pm, Jon Elson <jmel...@wustl.edu> wrote:
> rickman wrote:
>
> > If you build the Parllel Cable III into your product, what will you
> > connect it to? =A0I don't think they have built a PC with a parallel po=
rt
> > in a number of years and my understanding is that the drivers for USB
> > parallel ports don't work properly with bit banging software like this.
> > =A0 Am I mistaken? =A0Is this a workable solution?
>
> I have no idea about the USB-parport, but you CAN get computers with real
> parallel ports, just not on laptops. =A0I use the parallel port for lots
> of interconnect projects, and the Intel D525 chipset still has parport
> support, if the motherboard maker chooses to bring it out. =A0For this
> reason, we use a lot of Intel D525 (Atom) motherboards in projects.
>
> Jon

Yeah, sadly for us we have no control at all over what computers
people use, so we can't rely on parallel ports...

Thanks!

Article: 154251
Subject: Re: Looking for an extremely cheap FPGA board (in quantity, academic use)
From: Mark Brehob <brehob@gmail.com>
Date: Sun, 16 Sep 2012 08:53:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 10, 2:07=A0am, Simon <goo...@gornall.net> wrote:
> I think you're in luck...
>
> I was browsing around earlier today trying to figure out if I could do re=
altime video-rate JPEG encoding on a DSP instead of having to code it up in=
 verilog, and ran across this...
>
> =A0http://www.nuhorizons.com/development/board.asp?product=3DLattice-ICE4=
0...
>
> For $20, you get:
>
> =A0- 4 capacitive buttons. I guess you still have to 'debounce' capacitiv=
e buttons...
> =A0- 63 i/o on breadboard-friendly 0.1" headers. You'll have to supply th=
e headers.
> =A0- can power off the USB
> =A0- has ~1K logic cells (lut+flip-flop)
> =A0- comes with USB cable & software can be downloaded.
>
> Assuming you can solder some headers onto the board, switches can be repl=
aced by jumpers, and 63 i/o is actually really generous at this sort of lev=
el. Most of the entry-level boards are seriously miserly in comparison.
>
> On the downside, you'd probably not get much of a bulk discount - I'm gue=
ssing they're already cut to the bone at this price...
>
> Just FYI - not a recommendation since I've never used Lattice before, but=
 thought you'd be interested.
>
> Simon

That is _really_ close to what we are looking for, just the headers as
switches thing doesn't quite work.  And I'd really like a bit more
output LEDs. But very encouraging that what we want is possible,
thanks so much for the pointer!

Mark

Article: 154252
Subject: Re: Looking for an extremely cheap FPGA board (in quantity, academic
From: MK <mk@nospam.co.uk>
Date: Sun, 16 Sep 2012 18:12:11 +0100
Links: << >>  << T >>  << A >>
On 16/09/2012 16:53, Mark Brehob wrote:
> On Sep 10, 2:07 am, Simon <goo...@gornall.net> wrote:
>> I think you're in luck...
>>
>> I was browsing around earlier today trying to figure out if I could do realtime video-rate JPEG encoding on a DSP instead of having to code it up in verilog, and ran across this...
>>
>>   http://www.nuhorizons.com/development/board.asp?product=Lattice-ICE40...
>>
>> For $20, you get:
>>
>>   - 4 capacitive buttons. I guess you still have to 'debounce' capacitive buttons...
>>   - 63 i/o on breadboard-friendly 0.1" headers. You'll have to supply the headers.
>>   - can power off the USB
>>   - has ~1K logic cells (lut+flip-flop)
>>   - comes with USB cable & software can be downloaded.
>>
>> Assuming you can solder some headers onto the board, switches can be replaced by jumpers, and 63 i/o is actually really generous at this sort of level. Most of the entry-level boards are seriously miserly in comparison.
>>
>> On the downside, you'd probably not get much of a bulk discount - I'm guessing they're already cut to the bone at this price...
>>
>> Just FYI - not a recommendation since I've never used Lattice before, but thought you'd be interested.
>>
>> Simon
>
> That is _really_ close to what we are looking for, just the headers as
> switches thing doesn't quite work.  And I'd really like a bit more
> output LEDs. But very encouraging that what we want is possible,
> thanks so much for the pointer!
>
> Mark

Mark - you asked earlier about Lattice Diamond software. I've used 
Lattice parts a lot for the last 5 years and Diamond since it came out.
It works fine, not perfect, and nothing like as many whizzo features as 
the Xilinx stuff but it's cheap and it doesn't crash (at least for me.)

I would much rather work with Lattice parts than X or A, it's all well 
short of the bleeding edge and for just getting the job done at a 
reasonable cost it's fine.

Michael Kellett


Article: 154253
Subject: Re: Looking for an extremely cheap FPGA board (in quantity, academic
From: Johann Klammer <klammerj@NOSPAM.a1.net>
Date: Mon, 17 Sep 2012 06:43:44 +0200
Links: << >>  << T >>  << A >>
Mark Brehob wrote:
>
> Humm, it's sounding like Lattice is going to be the way to go unless I
> can get support from Altera or Xilinx (something I'll pursue if this
> gets out of the "idea" stage).
>
> Has anyone worked with Lattice Diamond?  How does it compare to the
> software from Xilinx and Altera?  I've been burned by some "bad" FPGA
> software in the past (not horrible, just too steep of a learning curve
> for the classroom) and would _really_ like the ability to do schematic
> capture in addition to Verilog...
>
> Thanks again to everyone for their responses, this has been really
> useful!
> Mark
Hello,

Tried to use Lattice software for several years now. It never worked. At 
first it did not work, because my windows installation was too old, and 
they did not have a linux install. I gave it a try at my brother's 
laptop, which was a bit more recent software-wise. Unfortunately their 
license is locked to the boxes' MAC address, so I had to wait for a 
year, to be able to apply for a new one. On that box it did not work 
either... unsure why.
Recent versions of lattice diamond are available for linux, so I gave it 
a try again. Synplify(the synthesis tool) failed with a SIGILL. It turns 
out it requires a SSE2 box.
Synplify is a synthesis tool, that is included in diamond. For some 
parts it is the only practical choice... It is produced by 'synopsys',
and they do not mention any instruction set requirements on their website...
http://www.synopsys.com/Tools/Implementation/FPGAImplementation/FPGASynthesis/Pages/FPGAPlatformSupport.aspx#requirements

The other synthesis tools supported are:
Precision: 3rd party (`mentor graphics`), not included, MachXO2 not 
supported.
Lattice LSE: Lattice Synthesis Engine, included. Available only with 
MachXO, MachXO2, and Platform Manager.

I did not try those, as they don't support LatticeXP parts... they 
_probably_ work.

All in all, things have improved. It might work on your common, everyday 
box.. if it isn't too old.

regards,
JK

Article: 154254
Subject: OpenTech the Largest Open Source package for FPGA designers
From: Khatib <jamil.khatib@gmail.com>
Date: Sun, 16 Sep 2012 22:03:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello,

I'd like to announce the new release of OpenTech Package 1.9.0, the first a=
nd the largest Open source EDA tools and open source hardware designs distr=
ibution package.

OpenTech is the first and largest world wide package of free open source ha=
rdware designs, EDA software and Books for electronics designs. Since 2000 =
we have sold OpenTech packages to Students, Professors, Engineers, Startup =
and even large corporations. In OpenTech package you will find many things =
that you can not imagine they even exist as open source. You will find CPUs=
 , Ethernet, USB and others. VHDL, Verilog, Schematic, IC and board layout =
and many many other software programs. In short you will find lot of inform=
ation that helps you in designing your system or testing it. The package is=
 composed of 5 DVDs that costs only 90 Euros. Use free open source tools an=
d designs in OpenTech package and save more than $500,000 and more than 3 m=
onths of search and download time.


This release is the 16th release since the start of OpenTech in 2000
and contains=20
- More than 16 GB of information distributed=20
- More than 380 Electronics related software
- More than 85  Hardware designs
- More than 670 Ope Cores
- More than 15 free books & tutorials
-=20
Since 2000 more than 660 shipped CDROMs/Packages all over the world.


This package is composed of 5 DVDs (Tools, Designs, Open Cores, and Books) =
and it features EDAutils (www.edautils.com) which supports the development =
and integration of SoC


We offer new service, we can help you in finding free designs or tools by p=
osting your requests to khatib@opencores.org and we will share the informat=
ion on our facebook page



Best regards,
Jamil Khatib
OpenTech maintainer
http://opentech.handasarabia.org
http://opencores.org/project,opentech
http://www.facebook.com/OpenTechPackage

Article: 154255
Subject: Re: Looking for an extremely cheap FPGA board (in quantity, academic
From: rickman <gnuarm@gmail.com>
Date: Mon, 17 Sep 2012 12:58:38 -0400
Links: << >>  << T >>  << A >>
On 9/17/2012 12:43 AM, Johann Klammer wrote:
> Mark Brehob wrote:
>>
>> Humm, it's sounding like Lattice is going to be the way to go unless I
>> can get support from Altera or Xilinx (something I'll pursue if this
>> gets out of the "idea" stage).
>>
>> Has anyone worked with Lattice Diamond? How does it compare to the
>> software from Xilinx and Altera? I've been burned by some "bad" FPGA
>> software in the past (not horrible, just too steep of a learning curve
>> for the classroom) and would _really_ like the ability to do schematic
>> capture in addition to Verilog...
>>
>> Thanks again to everyone for their responses, this has been really
>> useful!
>> Mark
> Hello,
>
> Tried to use Lattice software for several years now. It never worked. At
> first it did not work, because my windows installation was too old, and
> they did not have a linux install. I gave it a try at my brother's
> laptop, which was a bit more recent software-wise. Unfortunately their
> license is locked to the boxes' MAC address, so I had to wait for a
> year, to be able to apply for a new one. On that box it did not work
> either... unsure why.
> Recent versions of lattice diamond are available for linux, so I gave it
> a try again. Synplify(the synthesis tool) failed with a SIGILL. It turns
> out it requires a SSE2 box.
> Synplify is a synthesis tool, that is included in diamond. For some
> parts it is the only practical choice... It is produced by 'synopsys',
> and they do not mention any instruction set requirements on their
> website...
> http://www.synopsys.com/Tools/Implementation/FPGAImplementation/FPGASynthesis/Pages/FPGAPlatformSupport.aspx#requirements
>
>
> The other synthesis tools supported are:
> Precision: 3rd party (`mentor graphics`), not included, MachXO2 not
> supported.
> Lattice LSE: Lattice Synthesis Engine, included. Available only with
> MachXO, MachXO2, and Platform Manager.
>
> I did not try those, as they don't support LatticeXP parts... they
> _probably_ work.
>
> All in all, things have improved. It might work on your common, everyday
> box.. if it isn't too old.
>
> regards,
> JK


I have no idea why you could not get their tools to work.  I have never 
had trouble installing the tools other than the license issues which are 
common to all of these vendor supplied tools.  I have also never had 
trouble with getting duplicate licenses for new computers.  I don't know 
why you felt you needed to wait a year.  In fact, when I ask for a 
license renewal, they send me a license file for every machine I have 
ever registered with them!

The only real issue with any of the vendor packages are the IDEs which 
can be different.  Typically they try to emulate a Windows look and feel 
with some sort of a file manager-like GUI and some icons for the various 
files and/or processes of compiling code to produce a bit stream.

The "classic" ispLever is a little clunky in some ways, but it has never 
gotten in the way of doing work.  I have yet to try Diamond.

As to using schematic for any part of a design, I would point out that 
schematic for even top level design is rarely used in industry.  It has 
notable disadvantages with the lack of potability at the top of the 
list.  I suppose I can see why you might prefer it for teaching since it 
is very visual, but in the "real" world this will not be encouraged. 
Structural HDL is not hard to learn or use really.  So why teach 
techniques that are unlikely to be used?

Rick

Article: 154256
Subject: Re: Looking for an extremely cheap FPGA board (in quantity, academic use)
From: Jon Elson <jmelson@wustl.edu>
Date: Mon, 17 Sep 2012 14:09:44 -0500
Links: << >>  << T >>  << A >>
Mark Brehob wrote:


> Yeah, sadly for us we have no control at all over what computers
> people use, so we can't rely on parallel ports...
OK, one other thing is that due to export restrictions, no vendor's
free software can run on 64-bit operating systems.  There are ways to
hack links to libraries on Linux to get around this for Xilinx web pack
software, apparently.

Jon

Article: 154257
Subject: Re: Global Reset using Global Buffer
From: Carl <carwer0@gmail.com>
Date: Tue, 18 Sep 2012 07:31:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
An article on the local/global and synchronous/asynchronous aspects of resets:

http://www.fpga-dev.com/resets-make-them-synchronous-and-local/

Article: 154258
Subject: picoblaze help
From: rvm.rahul@gmail.com
Date: Tue, 18 Sep 2012 07:43:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
hello all,
I am new in the field of soft core processor.
I want to implement multiple picoblaze on spartan 3E.

I had gone through doc available on xilinx website.
All demo available on web is working fine with me.
I am trying to interface a seven segment with picoblaze but somehow i am not able to make my own design.

Please guide me for same.

Article: 154259
Subject: Re: picoblaze help
From: Tim Wescott <tim@seemywebsite.com>
Date: Tue, 18 Sep 2012 12:36:47 -0500
Links: << >>  << T >>  << A >>
On Tue, 18 Sep 2012 07:43:13 -0700, rvm.rahul wrote:

> hello all,
> I am new in the field of soft core processor. I want to implement
> multiple picoblaze on spartan 3E.
> 
> I had gone through doc available on xilinx website. All demo available
> on web is working fine with me. I am trying to interface a seven segment
> with picoblaze but somehow i am not able to make my own design.
> 
> Please guide me for same.

I can't help you much because I haven't done this, but I can tell you a 
bit:

First, you haven't told us everything.  Most importantly, how far did you 
get?  Have you gotten a picoblaze working on a test board?  How did you 
determine that it works?

Second: how are you trying to interface the seven-segment display to the 
Picoblaze?  

The obvious way to me (keeping in mind that I haven't played with a 
Picoblaze so I'm thinking like a board designer) would be to map a 
section of the Picoblaze's memory space to an 8-bit register that 
captures a byte on a write to a specific address, then connect that 
register to eight output pins on the FPGA.  Those output pins can then go 
to your seven segments (plus decimal point!), and you can write any 
arbitrary combination of "on" and "off" that you want.

I'd try to find a demo that shows how to get a Picoblaze working and 
"talking" to output pins on the FPGA and work from there.  If you're 
lucky there's a demo that shows how to get an 8-bit parallel output port 
to the outside world, in which case your FPGA firmware task is _done_ and 
all you need to do is write software.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Article: 154260
Subject: Re: Global Reset using Global Buffer
From: "jt_eaton" <1590@embeddedrelated>
Date: Tue, 18 Sep 2012 21:02:28 -0500
Links: << >>  << T >>  << A >>
>Hello Group
>
>I=B4ve read a lot about resets and I=B4ve decided that for my designs, an
>asynchronous solution with a synchronous source is a better solution.
>No discussions here, this is a personal (almost religious) choice.
>

Religious choice is an apt description. How else can you justify something
that has zero scientific evidence to support it?

What you are looking for is called a synchronous reset distribution tree.
Google that and you find some papers on it on Cliff Cumming's web site. It
is the only way to distribute an asynchronous assert/synchronous deassert
reset without skew.

Global resources are used when you have to deal with fast signals. PowerOn
reset is very very slow. Don't waste resources on it.

Remember that the reset system only has two requirements. 

  1) Force the chip into a known good state while the reset button is
pressed.

  2) Do nothing while the reset button is not pressed.

Most designers obsess over making sure the first condition is met while
barely considering the second one. This is odd because if you screw up
either one then your product will fail. Which one should keep you awake at
night?


Your product will spend 99.999999% of its power on time running and
susceptible to esd induced resets but it is only possible to have a power
on reset failure during the 0.000001% of the time that it is powering up.

Modern digital tool flows can easily catch design errors that would prevent
a chip reset in the RTL phase. Simulating esd events is a lot harder and
most of this  is done by QA testing.


These failures are asymmetric. If an esd event can get into your chip and
change state on a flop then your product is crap. If your power on reset
fails to reach a flop it will simply take on the next state value provided
by the mission mode logic. What will that be? It will almost always be the
same as the reset state.

The power on reset system has a good deal of redundancy.Everybody first
puts in a power on reset system and then adds their mission mode logic that
backs up the power on reset with the mission mode soft reset systems. You
can forget to connect a flop into the power on system and it will likely
still work.

It is almost impossible to screw up the reset system so that your product
fails to power up AND to do so in a way that your verification suite won't
catch it.

But it is very easy to have a esd entry path and not catch it till you get
the customer returns. You should first worry about preventing phantom
resets and after you have solved that then worry about getting power on
reset into your chip.


If you do that then you will never run an asynchronous reset signal down to
the core flops. Read Xilinx WP-231.


John Eaton

 



  




 
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154261
Subject: Re: Global Reset using Global Buffer
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 19 Sep 2012 03:33:52 +0000 (UTC)
Links: << >>  << T >>  << A >>
jt_eaton <1590@embeddedrelated> wrote:
>>Hello Group
>>
>>I=B4ve read a lot about resets and I=B4ve decided that for my designs, an
>>asynchronous solution with a synchronous source is a better solution.
>>No discussions here, this is a personal (almost religious) choice.

> Religious choice is an apt description. How else can you 
> justify something that has zero scientific evidence to support it?

> What you are looking for is called a synchronous reset distribution tree.
> Google that and you find some papers on it on Cliff Cumming's web site. It
> is the only way to distribute an asynchronous assert/synchronous deassert
> reset without skew.

For FPGAs, power up is always asynchronous, and you have to have
some way to get from configuration reset to operation.

> Global resources are used when you have to deal with fast signals. 
> PowerOn reset is very very slow. Don't waste resources on it.

Hopefully the FPGA designers did use (not waste) resources on it.

> Remember that the reset system only has two requirements. 

>  1) Force the chip into a known good state while the reset button is
> pressed.

>  2) Do nothing while the reset button is not pressed.

> Most designers obsess over making sure the first condition is met while
> barely considering the second one. This is odd because if you screw up
> either one then your product will fail. Which one should keep you awake at
> night?

If you can stop the clock until the system is out of reset and ready,
then there should be no problem. Otherwise, yes, you do have to be
very careful about the transition. 

-- glen

Article: 154262
Subject: Re: picoblaze help
From: goouse99@gmail.com
Date: Tue, 18 Sep 2012 23:46:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
Am Dienstag, 18. September 2012 16:43:14 UTC+2 schrieb rvm....@gmail.com:
> hello all,
> 
> I am new in the field of soft core processor.
> 
> I want to implement multiple picoblaze on spartan 3E.
> 
> 
> 
> I had gone through doc available on xilinx website.
> 
> All demo available on web is working fine with me.
> 
> I am trying to interface a seven segment with picoblaze but somehow i am not able to make my own design.
> 
> 
> 
> Please guide me for same.

Hi,
do you have some knowledge/experience with HDLs or digital design?

The PicoBlaze documentation shows very well how to add ports to the core and how to access these ports from the software. (Sorry Tim, there's no memory mapped I/O for the picoblaze. But the real solution is quite similar.)

Many beginners questions regarding the Picoblaze have already been answered and can be found here:
http://forums.xilinx.com/t5/PicoBlaze/bd-p/PicoBlaze

If there are still things unclear you should explain them in more detail.
- What board are you using?
- What is your design method (schematic, verilog, VHDL)?
- Where exactly are you haveing problems with your design? 
  (Error messages etc.) 

The above mentioned subforum might be a better place for this, since it is specialized on Picoblaze related topics.

Have a nice synthesis
  Eilert

Article: 154263
Subject: Re: Global Reset using Global Buffer
From: Christopher Head <chead@is.invalid>
Date: Wed, 19 Sep 2012 00:15:52 -0700
Links: << >>  << T >>  << A >>
On Tue, 18 Sep 2012 07:31:18 -0700 (PDT)
Carl <carwer0@gmail.com> wrote:

> An article on the local/global and synchronous/asynchronous aspects
> of resets:
> 
> http://www.fpga-dev.com/resets-make-them-synchronous-and-local/

Something that always seems to be missing when I read articles like
this is any mention whatsoever of the FPGA’s built-in reset
capabilities. For Xilinx Spartan FPGAs anyway, this is called
“GSR” (global set/reset). It’s certainly global, and I believe it’s
asynchronous. I don’t know what kind of skew it typically has, but it
has one wonderful benefit when it’s usable: it’s absolutely 100% free.
The GSR network is built into the chip whether you use it or not, so
using it to reset all your FFs costs absolutely nothing in terms of
LUTs and routing, something no other solution can claim. When dealing
with a nearly-full FPGA, that’s a very attractive property.

As far as issues of different FFs leaving reset on different clock
cycles are concerned, could one not solve these issues by asserting GSR
for long enough to reset all FFs, deassert it, then activate the clocks
afterwards? Using BUFGCEs (in Xilinx parlance) one could do this with a
very small chunk of logic, far less than the overhead of building
synchronous resets by routing the reset signal around the chip and then
feeding it into all the LUTs that make up feedback loops (increasing
LUT count in, say, one sixth of such cases where the LUT was already
populated by six inputs). Driving the ENABLE input of a canned
oscillator off a shift register of sufficient length clocked by the
internal configuration clock would probably achieve something similar.
Am I missing something about this proposed solution?

I really wish someone would write one of these articles about system
reset that acknowledges the existence of GSR and compares it to other
reset mechanisms and points out the advantages and disadvantages of
each. Unfortunately “someone” won’t be me, because I’m nowhere near an
FPGA expert and couldn’t hope to give it a proper treatment. Maybe
someone has written such an article, but I haven’t seen it.

Chris

Article: 154264
Subject: Re: Looking for an extremely cheap FPGA board (in quantity, academic use)
From: colin <colin_toogood@yahoo.com>
Date: Wed, 19 Sep 2012 03:20:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, 13 September 2012 20:03:07 UTC+1, Jon Elson  wrote:
> rickman wrote:
>=20
>=20
>=20
>=20
>=20
> >=20
>=20
> > If you build the Parllel Cable III into your product, what will you
>=20
> > connect it to?  I don't think they have built a PC with a parallel port
>=20
> > in a number of years and my understanding is that the drivers for USB
>=20
> > parallel ports don't work properly with bit banging software like this.
>=20
> >   Am I mistaken?  Is this a workable solution?
>=20
> I have no idea about the USB-parport, but you CAN get computers with real
>=20
> parallel ports, just not on laptops.  I use the parallel port for lots
>=20
> of interconnect projects, and the Intel D525 chipset still has parport
>=20
> support, if the motherboard maker chooses to bring it out.  For this
>=20
> reason, we use a lot of Intel D525 (Atom) motherboards in projects.
>=20
>=20
>=20
> Jon

I've been burnt by this. Xilinx use a proper plug and play driver for their=
 parallel cable IV and will therefore work with a very cheap PCI parallel p=
ort card. ALTERA don't, their driver insists on the parallel port being whe=
re IBM put it in IO space 30 odd years ago.

Colin

Article: 154265
Subject: Re: Global Reset using Global Buffer
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Wed, 19 Sep 2012 10:28:01 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Wed, 19 Sep 2012 00:15:52 -0700, Christopher Head wrote:

> On Tue, 18 Sep 2012 07:31:18 -0700 (PDT)
> Carl <carwer0@gmail.com> wrote:
> 
>> An article on the local/global and synchronous/asynchronous aspects of
>> resets:
>> 
>> http://www.fpga-dev.com/resets-make-them-synchronous-and-local/
> 
> Something that always seems to be missing when I read articles like this
> is any mention whatsoever of the FPGA’s built-in reset capabilities. For
> Xilinx Spartan FPGAs anyway, this is called “GSR” (global set/reset).
> 
> As far as issues of different FFs leaving reset on different clock
> cycles are concerned, could one not solve these issues by asserting GSR
> for long enough to reset all FFs, deassert it, then activate the clocks
> afterwards? 

Yes. Perhaps better, activate clock enable(s) afterwards.

Either way, you may need a hierarchy of clock activation; after reset, 
you don't want your main clock generator to wait for several cycles of a 
(stopped) clock... 

- Brian

Article: 154266
Subject: Re: Looking for an extremely cheap FPGA board (in quantity, academic use)
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 19 Sep 2012 13:23:38 +0000 (UTC)
Links: << >>  << T >>  << A >>
colin <colin_toogood@yahoo.com> wrote:

(snip on FPGA programming)

> I've been burnt by this. Xilinx use a proper plug and play 
> driver for their parallel cable IV and will therefore work 
> with a very cheap PCI parallel port card. ALTERA don't, 
> their driver insists on the parallel port being where IBM 
> put it in IO space 30 odd years ago.

Go through the binary code of the driver and replace the port
number with the desired, different, port number.

I suppose that could also change something else, but it might work.

-- glen

Article: 154267
Subject: Re: Global Reset using Global Buffer
From: jonesandy@comcast.net
Date: Wed, 19 Sep 2012 07:38:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, September 18, 2012 9:02:29 PM UTC-5, jt_eaton wrote:
>If you do that then you will never run an asynchronous reset signal down to the core flops. Read Xilinx WP-231. 

I've read WP-231, and it best be taken with a big dose of salt, like most generalizations. Please note the date, and the applicable series of FPGAs.

If we are trying to avoid religion, "never" is a very long time and is almost certainly untrue. 

There are many valid reasons to use an asynchronous reset, and many valid reasons to use a synchronous reset. Let's just leave it at that, without all the pontifications invoking "never" (or "always").

Besides, the OP's Q has nothing to do with async vs sync reset; both usually need to meet timing anyway.

Andy

Article: 154268
Subject: Re: Global Reset using Global Buffer
From: "jt_eaton" <1590@embeddedrelated>
Date: Wed, 19 Sep 2012 09:50:35 -0500
Links: << >>  << T >>  << A >>
>On Wed, 19 Sep 2012 00:15:52 -0700, Christopher Head wrote:
>
>> On Tue, 18 Sep 2012 07:31:18 -0700 (PDT)
>> Carl <carwer0@gmail.com> wrote:
>> 
>>> An article on the local/global and synchronous/asynchronous aspects of
>>> resets:
>>> 
>>> http://www.fpga-dev.com/resets-make-them-synchronous-and-local/
>> 
>> Something that always seems to be missing when I read articles like
this
>> is any mention whatsoever of the FPGA’s built-in reset capabilities.
For
>> Xilinx Spartan FPGAs anyway, this is called “GSR” (global
set/reset).
>> 
>> As far as issues of different FFs leaving reset on different clock
>> cycles are concerned, could one not solve these issues by asserting GSR
>> for long enough to reset all FFs, deassert it, then activate the clocks
>> afterwards? 
>
>Yes. Perhaps better, activate clock enable(s) afterwards.
>
>Either way, you may need a hierarchy of clock activation; after reset, 
>you don't want your main clock generator to wait for several cycles of a 
>(stopped) clock... 
>
>- Brian
>

Guys,

You don't need to stop the clock at all. The reset deassert to clock edge 
spec only applies when you are trying to change state. So if you reset
the flop to 0 and have a 1 sitting on the D input then you must meet
timing or it will go metastable. If you have a 0 on the D input then
it doesn't matter if you meet timing. The flop will stay at 0.


Most designs already do this. When an ethernet interface comes out of
reset
it doesn't suddenly start ethernetting, It waits for the CPU to write
setup
and other data before it does anything. That means that once all of its
flops
are in reset state then they all have that reset state applied to their D
inputs until the first cpu write. 

You can deassert a asynchronous reset at any time as long as your 
asynchronous reset system is backed up with a synchronous one provided
by the mission mode logic. You do have to be careful with the cpu or any
other block that self starts but thats easy to deal with.



John Eaton





	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154269
Subject: Re: Global Reset using Global Buffer
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Wed, 19 Sep 2012 16:06:28 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Wed, 19 Sep 2012 09:50:35 -0500, jt_eaton wrote:

>>On Wed, 19 Sep 2012 00:15:52 -0700, Christopher Head wrote:

>>> As far as issues of different FFs leaving reset on different clock
>>> cycles are concerned, could one not solve these issues by asserting
>>> GSR for long enough to reset all FFs, deassert it, then activate the
>>> clocks afterwards?
>>
>>Yes. Perhaps better, activate clock enable(s) afterwards.
>>
>>Either way, you may need a hierarchy of clock activation; after reset,
>>you don't want your main clock generator to wait for several cycles of a
>>(stopped) clock...
>>
>>- Brian
>>
>>
> Guys,
> 
> You don't need to stop the clock at all. The reset deassert to clock
> edge spec only applies when you are trying to change state. 

I know. But I was being a little facetious, after one occasion when I 
shot myself in the foot with a synchronous reset for a DLL...

- Brian

Article: 154270
Subject: Re: Global Reset using Global Buffer
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Wed, 19 Sep 2012 16:06:58 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Wed, 19 Sep 2012 09:50:35 -0500, jt_eaton wrote:

>>On Wed, 19 Sep 2012 00:15:52 -0700, Christopher Head wrote:

>>> As far as issues of different FFs leaving reset on different clock
>>> cycles are concerned, could one not solve these issues by asserting
>>> GSR for long enough to reset all FFs, deassert it, then activate the
>>> clocks afterwards?
>>
>>Yes. Perhaps better, activate clock enable(s) afterwards.
>>
>>Either way, you may need a hierarchy of clock activation; after reset,
>>you don't want your main clock generator to wait for several cycles of a
>>(stopped) clock...
>>
>>- Brian
>>
>>
> Guys,
> 
> You don't need to stop the clock at all. The reset deassert to clock
> edge spec only applies when you are trying to change state. 

I know. But I was being a little facetious, after one occasion when I 
shot myself in the foot with a synchronous reset for a DLL...

- Brian

Article: 154271
Subject: Re: Global Reset using Global Buffer
From: "jt_eaton" <1590@embeddedrelated>
Date: Wed, 19 Sep 2012 11:49:30 -0500
Links: << >>  << T >>  << A >>

>
>I've read WP-231, and it best be taken with a big dose of salt, like most
generalizations. Please note the date, and the applicable series of FPGAs.
>
>Andy
>

It's dated 2006. While that is considered old in some parts of this
industry it is very modern when it comes to reset systems. The global async
assert/sync
deassert reset that is prevalent through out the IC world has been around 
since the 1980's and was derived from the board level reset systems used
back 
in the days of disco.

The important thing about WP-231 is that it was written by the engineers
that
are the experts on the silicon and tools and provides very specific
examples
of why decades old design practices  are not optimal for todays deep
submicron processes

A lot of advice that you hear from component designers is out of date and 
should be ignored, but when the people who wear bunny suits at work give
you advice then you really need to listen.


John Eaton

 	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154272
Subject: Re: Global Reset using Global Buffer
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 19 Sep 2012 17:43:46 +0000 (UTC)
Links: << >>  << T >>  << A >>
jt_eaton <1590@embeddedrelated> wrote:

(snip)

> You don't need to stop the clock at all. The reset deassert to clock edge 
> spec only applies when you are trying to change state. So if you reset
> the flop to 0 and have a 1 sitting on the D input then you must meet
> timing or it will go metastable. If you have a 0 on the D input then
> it doesn't matter if you meet timing. The flop will stay at 0.

More specifically, if your FFs have a clock enable input, and you
can be sure that they are not enabled as they come out of reset,
then you don't have to worry about the clock timing.

> Most designs already do this. When an ethernet interface comes out of
> reset it doesn't suddenly start ethernetting, It waits for the 
> CPU to write setup and other data before it does anything. 
> That means that once all of its flops are in reset state then 
> they all have that reset state applied to their D inputs until 
> the first cpu write. 

There has to be at least one FF with the enable determined though
outside logic, but that should be usual in the case of a processor.

> You can deassert a asynchronous reset at any time as long as your 
> asynchronous reset system is backed up with a synchronous one provided
> by the mission mode logic. You do have to be careful with the cpu or any
> other block that self starts but thats easy to deal with.

-- glen

Article: 154273
Subject: Querying Active-HDL from TCL
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Wed, 19 Sep 2012 10:54:47 -0700
Links: << >>  << T >>  << A >>
This is only approximately the right place to be asking this, but if
anyone's going to have an answer, I figure it'll be here.

Does anyone know how actually find anything about a design out from a
TCL script in Aldec Active-HDL.  Not anything particularly complicated,
things like a list of the active libraries, or what models have
been compiled into them.  Or what files are in a design.  Or whether or
not a simulation is currently running.

These all seem like trivial and reasonable things to want to know, but I
haven't been able to find any documentation telling me how.  I can use
vlib to create a library, but there doesn't seem to be a call telling
me whether or not a library exists.

Anyone know anything on this?  Advice for how to do it under ModelSim
would help too; there's a lot of cross-over.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 154274
Subject: Re: Querying Active-HDL from TCL
From: HT-Lab <hans64@htminuslab.com>
Date: Wed, 19 Sep 2012 21:22:13 +0100
Links: << >>  << T >>  << A >>
On 19/09/2012 18:54, Rob Gaddi wrote:
> This is only approximately the right place to be asking this, but if
> anyone's going to have an answer, I figure it'll be here.
>
> Does anyone know how actually find anything about a design out from a
> TCL script in Aldec Active-HDL.  Not anything particularly complicated,
> things like a list of the active libraries, or what models have
> been compiled into them.  Or what files are in a design.  Or whether or
> not a simulation is currently running.
>
> These all seem like trivial and reasonable things to want to know, but I
> haven't been able to find any documentation telling me how.  I can use
> vlib to create a library, but there doesn't seem to be a call telling
> me whether or not a library exists.
>
> Anyone know anything on this?  Advice for how to do it under ModelSim
> would help too; there's a lot of cross-over.
>

I don't know Active HDL but in Modelsim you have the report command 
which can give you bit and pieces like file list, the state of the 
simulator, log file locations etc.

You can use the vmap command to list the libraries which are mapped in 
the modelim.ini file. This does not however tell you which libraries are 
actually used, it simply echoes the modelsim.ini [Library] section.

The vdir command spews out lots of information on a design unit (or 
whole library).

Another useful command (but currently broken in the 10.1x release) is 
the "echo [StartupGetArgs]" command which is useful to find out how 
Modelsim was invoked (not always clear if invoked from another tool like 
HDL Designer, ISE etc).

Regards,
Hans.
www.ht-lab.com





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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

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