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 155900

Article: 155900
Subject: Re: extra reset pin should not be needed..
From: GaborSzakacs <gabor@alacron.com>
Date: Mon, 14 Oct 2013 15:57:12 -0400
Links: << >>  << T >>  << A >>
Joseph H Allen wrote:
> In article <l3gq1p$ua8$1@dont-email.me>,
> GaborSzakacs  <gabor@alacron.com> wrote:
>> Joseph H Allen wrote:
>>> In article <l3d4aa$dmi$1@dont-email.me>, Gabor  <gabor@szakacs.org> wrote:
> 
>>>> reg [3:0] foo = 4'd7;
> 
>>> Yeah I've been playing with this, it does work, but has the disadvantage
>>> that your code will then be different from RTL for an ASIC..  I mean if you
>>> used these initial values for all flops in the design, then you would not
>>> need an explicit reset net at all.  I'm pretty sure design compiler will not
>>> support it.
> 
> BTW, this syntax works for Synplify, but not for Lattice's new LSE.
> 
> Also I discovered that switching between synthesis tools breaks the pin
> assignments.
> 
>>>> In all the years I've used Xilinx tools and FPGA's I don't think
>>>> I ever actually assigned a package pin for a reset, although I
>>>> typically have an internally generated reset net using a short
>>>> shift register that initializes to all ones and shifts in zero
>>>> after power-up.
> 
>>> This means you will not be able to use the FPGA's already existing global
>>> reset net in place of one which takes up routing resources.  This one shift
>>> register will prevent you from making the explicit reset net equal to the
>>> built-in one (which only works if all flops in the entire design are
>>> connected to the same net).
> 
>>> Anyway, it's not such a big deal with the chips these days, but still it
>>> would be nice if there was a way to do it.  The initial value is a good way
>>> to make an internal reset generator as you say.
> 
>> Now that I think of it, Lattice has a way to use the global reset net
>> internally.  At least in the last parts I used (ECP and ECP2) you could
>> do essentially the same business I did with Xilinx, and then tie the
>> output of the shift register to the global reset net.  The reason this
>> works in Lattice and not Xiinx is that the Lattice parts allow you to
>> remove the global reset function on a flop-by-flop basis.  Thus you
>> turn off global reset on the reset S/R itself.
> 
> I found the part of Lattice's documentation which talks about this- it's
> quite elborate (complex).  It looks like the default is to use GSR for the
> largest reset net, and disable it for any others.  I'm surprised that they
> found it worthwhile to add this configuration bit to every flop in the chip.
> 
> I wonder if flops with GSR disabled are really in an indeterminate state out
> of configuration... I guess it could be either way: if they clear the config
> bit chain and hit the global reset before loading the design they would get
> cleared..
> 
> 
> 

Here's a snippet of an ECP2 project.  The "FD1P3AX" is a library element
and it is reset to zero at configuration (this is an SRAM part like
Xilinx).  However it is not connected to the GSR net.  Note that I
also specify the GSR net, rather than get surprised when the ispLever
software decides to connect it to some other net.  I've been burned
by that before.

Remember in these parts, the configuration bitstream contains the
initial value of all flops, which does not need to be the same
as the reset value, but defaults to that.  This also used to be true
of Xilinx parts, but newer ones require an asynch reset to match the
configuration init value.  So in fact without GSR you still come
up in a known state after configuration.  This is not literally a
"reset" function, but the equivalent of shifting the data into
the flops during configuration.  In the same way you can initialize
all your BRAM and SRL's (yeah Lattice has those, too), even though
they have no "reset" function.

// --------------------------------------------------------------------
// Instantiate flip-flops for internal reset signals
// This flip-flop comes up reset after configuration.
FD1P3AX sysclk_rst_ff
(
   .D  (1'b1),
   .SP (1'b1),
   .CK (sys_clock),
   .Q  (sysclk_rstn)
);

assign sys_reset = !sysclk_rstn;

// Prevent GSR from resetting its own source:
parameter DISABLED_GSR = "DISABLED";
defparam sysclk_rst_ff.GSR = DISABLED_GSR;

GSR     GSR_INST
(
   // Global set/reset is active low:
   .GSR (sysclk_rstn)
);

-- 
Gabor

Article: 155901
Subject: Re: reset strategy FPGA Igloo
From: alb <alessandro.basili@cern.ch>
Date: Mon, 14 Oct 2013 22:35:32 +0200
Links: << >>  << T >>  << A >>
On 13/10/2013 05:18, rickman wrote:
[]
>> Apparently I have not found a 'global reset line' for the igloo family,
>> but there's an interesting application note from Actel/Microsemi on
>> their Flash-based devices which I find quite interesting:
>>
>> http://www.actel.com/documents/LPF_AC380_AN.pdf
> 
> Wow, if Actel doesn't have a global reset line I have no idea how they
> make their parts work.  

please do not take my words for granted. Maybe I haven't looked careful
enough. OTOH I've worked with Actel components since a lot and found
them very easy to handle (provided the board designer puts in a powerup
reset circuitry!).

> I haven't read the above app note, but the way
> most brands of FPGAs work, there is a global reset line which holds the
> user logic in reset until the end of config.  This like is similar to a
> global clock line, but without the high speed drive.  When the reset is
> released the entire chip can start.  The problem is the delay on this
> line is long enough to cause problems releasing the entire design on the
> same clock cycle.

They are 'live at power up' (LAPU). See here for more information:

http://www.zlgmcu.com/Microsemi/SOC/igloo/LAPU_PIB.pdf

(warning: it took me a long time to download the file even though the
size is relatively small - 727KB)

> 
> It is seldom that an entire FPGA design has to start on the same clock
> edge.  I design individual circuits to start up on a local copy of the
> reset.  Or better still is to design them so they start in an idle state
> waiting for something else to happen which will take a clock cycle or
> two providing enough delay that they don't need a synchronous reset.

I agree with what Alan says: "Designing for all-IDLE FSMs is the proper
approach but doesn't eliminate the need to have an explicit reset"

>> it seems that 'weak pull-up/down' will be activated as soon as Vcc and
>> Vcci are above functional threshold, which is essentially enough to have
>> a logic '1' driven at the input of the POR proposed in the other note.
> 
> Are you saying you have designed the board without consideration to
> resetting the FPGA?  I can't imagine the Actel parts require an external
> reset.  I'm glad I am finding this out now.

I jumped in the project far after those details were left out of the
design phase. How do you reset your logic only through the internal
resources of your device?

Article: 155902
Subject: Re: reset strategy FPGA Igloo
From: rickman <gnuarm@gmail.com>
Date: Mon, 14 Oct 2013 21:37:52 -0400
Links: << >>  << T >>  << A >>
On 10/13/2013 7:39 AM, Alan Reynolds wrote:
> On 2013-10-13 03:18:43 +0000, rickman said:
>
>> On 10/11/2013 5:46 PM, alb wrote:
>>> Hi Glen,
>>>
>>> On 11/10/2013 19:52, glen herrmannsfeldt wrote:
>>> []
>>>>> My question here is the following: should I route the 'lock'
>>>>> signal to a special buffer to minimize delays or would it be
>>>>> sufficient to use it as is?
>>>>
>>>> First, I agree with what Mark says.
>>>
>>> and I also start to believe my reset strategy is weak!
>>>
>>>> In addition, note that most FPGA families have a global reset line
>>>> similar to the global clock lines. They usually keep all the FF held
>>>> at reset until configuration is done, and also allow you to use that
>>>> reset line. It is there, it is free, and you might was well use it.
>>>
>>> Apparently I have not found a 'global reset line' for the igloo family,
>>> but there's an interesting application note from Actel/Microsemi on
>>> their Flash-based devices which I find quite interesting:
>>>
>>> http://www.actel.com/documents/LPF_AC380_AN.pdf
>>
>> Wow, if Actel doesn't have a global reset line I have no idea how they
>> make their parts work. I haven't read the above app note, but the way
>> most brands of FPGAs work, there is a global reset line which holds
>> the user logic in reset until the end of config. This like is similar
>> to a global clock line, but without the high speed drive. When the
>> reset is released the entire chip can start. The problem is the delay
>> on this line is long enough to cause problems releasing the entire
>> design on the same clock cycle.
>
> Actel/Microsemi FPGAs are FLASH so don't need configuration. You have to
> reset them in the same way you would an ASIC.

I don't think that is relevant to the discussion.  What you call it 
doesn't matter, the point is that the device must have some way to reset 
all the user FFs at power up and also when controlled by the user.  In 
the Xilinx devices the problem comes from the fact that this global 
reset signal is not fast enough to assure all FFs are reset or released 
from reset in the same clock cycle.  That is the issue.

So do the Actel devices have a global reset/set signal?  Is it fast 
enough to control all FFs in the same clock cycle?


>> It is seldom that an entire FPGA design has to start on the same clock
>> edge. I design individual circuits to start up on a local copy of the
>> reset. Or better still is to design them so they start in an idle
>> state waiting for something else to happen which will take a clock
>> cycle or two providing enough delay that they don't need a synchronous
>> reset.
>
> Designing for all-IDLE FSMs is the proper approach but doesn't eliminate
> the need to have an explicit reset. Global resources are typically used
> for the RESET even when timing is not an issue to remove the routing
> burden of thousands of loads. The locally copied RESETs are usually only
> useful if you need to support synchronous resets.

Yes, I agree, but I don't get your point.  I am discussing the global 
reset signal, does the Actel devices have one.

The local resets are for things that *do* need to start up on the same 
clock cycle; call it a synchronous reset then.  A free running state 
machine is a good example.  A counter is another.

-- 

Rick

Article: 155903
Subject: Re: reset strategy FPGA Igloo
From: rickman <gnuarm@gmail.com>
Date: Mon, 14 Oct 2013 21:59:34 -0400
Links: << >>  << T >>  << A >>
On 10/14/2013 4:35 PM, alb wrote:
> On 13/10/2013 05:18, rickman wrote:
> []
>>> Apparently I have not found a 'global reset line' for the igloo family,
>>> but there's an interesting application note from Actel/Microsemi on
>>> their Flash-based devices which I find quite interesting:
>>>
>>> http://www.actel.com/documents/LPF_AC380_AN.pdf
>>
>> Wow, if Actel doesn't have a global reset line I have no idea how they
>> make their parts work.
>
> please do not take my words for granted. Maybe I haven't looked careful
> enough. OTOH I've worked with Actel components since a lot and found
> them very easy to handle (provided the board designer puts in a powerup
> reset circuitry!).

I'm trying to understand what you *are* saying about the reset.  Does 
Actel provide a mechanism so that each FF is brought out of reset on the 
same clock cycle?  This makes a *big* difference in how you design your 
reset operation.

I think you are saying the FPGA has an external reset pin which the 
board controls.  Good.  Does your board control that?  What does the 
reset do on the FPGA exactly?


>> I haven't read the above app note, but the way
>> most brands of FPGAs work, there is a global reset line which holds the
>> user logic in reset until the end of config.  This like is similar to a
>> global clock line, but without the high speed drive.  When the reset is
>> released the entire chip can start.  The problem is the delay on this
>> line is long enough to cause problems releasing the entire design on the
>> same clock cycle.
>
> They are 'live at power up' (LAPU). See here for more information:
>
> http://www.zlgmcu.com/Microsemi/SOC/igloo/LAPU_PIB.pdf
>
> (warning: it took me a long time to download the file even though the
> size is relatively small - 727KB)

I don't care if they are live at power up.  Is that relevant?  I'm 
trying to understand the reset process.


>> It is seldom that an entire FPGA design has to start on the same clock
>> edge.  I design individual circuits to start up on a local copy of the
>> reset.  Or better still is to design them so they start in an idle state
>> waiting for something else to happen which will take a clock cycle or
>> two providing enough delay that they don't need a synchronous reset.
>
> I agree with what Alan says: "Designing for all-IDLE FSMs is the proper
> approach but doesn't eliminate the need to have an explicit reset"

Maybe I don't understand what you are saying at all.  Hopefully you will 
explain exactly what the problem is.  Is there *no* reset to the FPGA on 
your board?


>>> it seems that 'weak pull-up/down' will be activated as soon as Vcc and
>>> Vcci are above functional threshold, which is essentially enough to have
>>> a logic '1' driven at the input of the POR proposed in the other note.
>>
>> Are you saying you have designed the board without consideration to
>> resetting the FPGA?  I can't imagine the Actel parts require an external
>> reset.  I'm glad I am finding this out now.
>
> I jumped in the project far after those details were left out of the
> design phase. How do you reset your logic only through the internal
> resources of your device?

So are you saying there is no external reset on the board for the FPGA? 
  Why can't you add one?  The need for this seems like a no-brainer even 
if it is a white wire job.

If there is no reset, what can you know about the state of the FFs on 
powerup?  If they are random, I don't think you can make this work 
without a power up reset.

Ah!  I went back to your initial post about the PLL lock signal. 
Assuming this signal is meaningful at all times I would expect it to be 
"unlock" (as opposed to "lock") at power up.  If that is true then I 
think you can condition it to give you a reset to your logic.

A small circuit consisting of a long period counter can be held in reset 
while the PLL is not locked.  The rest of the design is held in reset by 
the counter.  When the counter reaches its final state, implying the PLL 
lock signal has been valid long enough to actually indicate a true PLL 
lock, the reset to the rest of the logic is released.

Maybe this is obvious to you.  If so, I don't understand what your 
question is.

To tell you the truth, I would try discussing this with an Actel FAE. 
Hopefully they know the answer.

-- 

Rick

Article: 155904
Subject: Re: Xilinx tools for XC3020???
From: rickman <gnuarm@gmail.com>
Date: Mon, 14 Oct 2013 22:24:07 -0400
Links: << >>  << T >>  << A >>
On 4/4/2013 6:20 PM, Mike Butts wrote:
> Hi Paul,
>
> It's a plain XC3020. I installed a 2001 Student Edition on my Win7 machine, and it appears to run. All it needed was the license code that came with the CD-ROM.
>
> I'm pretty sure XC3020 and XC3020A differ only in timing and the same bitfile can work on both. Anyway I'll be finding out sometime soon and I'll post how it goes.
> Thanks all!

I take it you are on your way.  I found my old Xilinx software *and* 
what I think are the dongles for it, a couple three of them.  I believe 
the oldest version is Foundation 1.4, but I'm not sure as I seem to have 
left the box will it all at my other place.

I actually promised this to someone so I need to find his email and tell 
him I can ship it if he is still interested.

I also have a set of floppies with ViewLogic (if I remember the right 
name)... they *are* 3.5 inch floppies, not 5 1/4.  :p

-- 

Rick

Article: 155905
Subject: Re: Vivado HLS -> Vivado IDE -> Xilinx SDK toolflow integration issue
From: mormegil231 <turin231@gmail.com>
Date: Tue, 15 Oct 2013 02:12:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
Fix the issue with the help of a reply in the xilinx forum...I had to use s=
w_sdk_repo for the custom repository folder for the sdk to see it correctly=
...

On Monday, October 14, 2013 1:44:52 PM UTC+2, mormegil231 wrote:
> Hello all,
>=20
>=20
>=20
> I have been using Vivado HLS to create an IP to later use the rest of the=
 toolflow to implement a system using a Microblaze and the HLS IP. HLS acta=
ully automatically creates drivers for programming the system and controlli=
ng it through the Microblaze.I need to use this tooflow since i onyl have a=
 virtex 7 available and use 7-series only xilinx IPs. So to go by the old E=
DK flow is not an option.=20
>=20
>=20
>=20
> These are supposed to be imported in SDK. the problem is that SDK do not =
recognize the drivers and as such the IP in SDK is defined as having generi=
c driver instead if its own. I did change the repository to point at the HL=
S drivers but still i do not get the option to use the HLS driver.=20
>=20
>=20
>=20
> I am thinking that it is a naming issue...My IP's name is ComputeNetwork.=
 What I see is that in the MDD files the HLS IP adds in the naming of the s=
upported peripherals version stuff...
>=20
>=20
>=20
>  http://img826.imageshack.us/img826/3314/1yl2.png
>=20
>=20
>=20
>=20
>=20
> Yet the IDE and SDK see my IP just as a ComputeNetwork component:
>=20
>=20
>=20
> http://img197.imageshack.us/img197/1047/4nmf.png
>=20
>=20
>=20
>=20
>=20
> http://img62.imageshack.us/img62/5428/2fwx.png
>=20
>=20
>=20
> Did not get any answers in the xilinx forum...Any ideas about the issue w=
ill be greatly appreciated.
>=20
>=20
>=20
> Thanks a lot,
>=20
> George


Article: 155906
Subject: Re: reset strategy FPGA Igloo
From: Alan Reynolds <abreynolds@me.com>
Date: Tue, 15 Oct 2013 08:34:03 -0400
Links: << >>  << T >>  << A >>
On 2013-10-15 01:59:34 +0000, rickman said:

> On 10/14/2013 4:35 PM, alb wrote:
>> On 13/10/2013 05:18, rickman wrote:
>> []
>>>> Apparently I have not found a 'global reset line' for the igloo family,
>>>> but there's an interesting application note from Actel/Microsemi on
>>>> their Flash-based devices which I find quite interesting:
>>>> 
>>>> http://www.actel.com/documents/LPF_AC380_AN.pdf
>>> 
>>> Wow, if Actel doesn't have a global reset line I have no idea how they
>>> make their parts work.
>> 
>> please do not take my words for granted. Maybe I haven't looked careful
>> enough. OTOH I've worked with Actel components since a lot and found
>> them very easy to handle (provided the board designer puts in a powerup
>> reset circuitry!).
> 
> I'm trying to understand what you *are* saying about the reset.  Does 
> Actel provide a mechanism so that each FF is brought out of reset on 
> the same clock cycle?  This makes a *big* difference in how you design 
> your reset operation.

Non-FLASH FPGAs have to be configured on power-on so the reseting of 
FFs is a by-product of that activity which allows for the deassertion 
of the configuration RESET *after* every FF has been configured to a 
known value.  Like an ASIC, Actel parts require and explicit POR 
because they do not have a configuration sequence. If the POR signal 
(or logic output) is placed on a global net and your design frequency 
is below insertion delay plus skew of the global net and the POR is 
synchronously deasserted then every FF in the chip will be in the reset 
state in the same clock cycle. Again, this is the same consideration 
you have to use when reseting an ASIC.

> 
> I think you are saying the FPGA has an external reset pin which the 
> board controls.  Good.  Does your board control that?  What does the 
> reset do on the FPGA exactly?
> 
> 
>>> I haven't read the above app note, but the way
>>> most brands of FPGAs work, there is a global reset line which holds the
>>> user logic in reset until the end of config.  This like is similar to a
>>> global clock line, but without the high speed drive.  When the reset is
>>> released the entire chip can start.  The problem is the delay on this
>>> line is long enough to cause problems releasing the entire design on the
>>> same clock cycle.
>> 
>> They are 'live at power up' (LAPU). See here for more information:
>> 
>> http://www.zlgmcu.com/Microsemi/SOC/igloo/LAPU_PIB.pdf
>> 
>> (warning: it took me a long time to download the file even though the
>> size is relatively small - 727KB)
> 
> I don't care if they are live at power up.  Is that relevant?  I'm 
> trying to understand the reset process.

No configuration sequence means no global reset.

> 
> 
>>> It is seldom that an entire FPGA design has to start on the same clock
>>> edge.  I design individual circuits to start up on a local copy of the
>>> reset.  Or better still is to design them so they start in an idle state
>>> waiting for something else to happen which will take a clock cycle or
>>> two providing enough delay that they don't need a synchronous reset.
>> 
>> I agree with what Alan says: "Designing for all-IDLE FSMs is the proper
>> approach but doesn't eliminate the need to have an explicit reset"
> 
> Maybe I don't understand what you are saying at all.  Hopefully you 
> will explain exactly what the problem is.  Is there *no* reset to the 
> FPGA on your board?
> 
> 
>>>> it seems that 'weak pull-up/down' will be activated as soon as Vcc and
>>>> Vcci are above functional threshold, which is essentially enough to have
>>>> a logic '1' driven at the input of the POR proposed in the other note.
>>> 
>>> Are you saying you have designed the board without consideration to
>>> resetting the FPGA?  I can't imagine the Actel parts require an external
>>> reset.  I'm glad I am finding this out now.
>> 
>> I jumped in the project far after those details were left out of the
>> design phase. How do you reset your logic only through the internal
>> resources of your device?
> 
> So are you saying there is no external reset on the board for the FPGA? 
>   Why can't you add one?  The need for this seems like a no-brainer 
> even if it is a white wire job.
> 
> If there is no reset, what can you know about the state of the FFs on 
> powerup?  If they are random, I don't think you can make this work 
> without a power up reset.
> 
> Ah!  I went back to your initial post about the PLL lock signal. 
> Assuming this signal is meaningful at all times I would expect it to be 
> "unlock" (as opposed to "lock") at power up.  If that is true then I 
> think you can condition it to give you a reset to your logic.
> 
> A small circuit consisting of a long period counter can be held in 
> reset while the PLL is not locked.  The rest of the design is held in 
> reset by the counter.  When the counter reaches its final state, 
> implying the PLL lock signal has been valid long enough to actually 
> indicate a true PLL lock, the reset to the rest of the logic is 
> released.

This is a perfectly reasonable approach and one that I have used when 
the stability of LOCK was a potential issue.

> 
> Maybe this is obvious to you.  If so, I don't understand what your question is.
> 
> To tell you the truth, I would try discussing this with an Actel FAE. 
> Hopefully they know the answer.



Article: 155907
Subject: Re: Xilinx tools for XC3020???
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Tue, 15 Oct 2013 13:42:58 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <l3i913$1af$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>On 4/4/2013 6:20 PM, Mike Butts wrote:
>> Hi Paul,

>> It's a plain XC3020. I installed a 2001 Student Edition on my Win7 machine, and it
>appears to run. All it needed was the license code that came with the CD-ROM.

>> I'm pretty sure XC3020 and XC3020A differ only in timing and the same bitfile can work
>on both. Anyway I'll be finding out sometime soon and I'll post how it goes.
>> Thanks all!

>I take it you are on your way.  I found my old Xilinx software *and* 
>what I think are the dongles for it, a couple three of them.  I believe 
>the oldest version is Foundation 1.4, but I'm not sure as I seem to have 
>left the box will it all at my other place.

I can confirm that Xilinx XACT runs on Windows-XP (with the dongle).  You
can hand-edit your XC2064s :-)

Also, I remember that early versions of Foundation were tied to the
partition serial number in the MBR (which you can easily change with DOS
"debug" command).  I mean the first versions which finally got rid of the
dongle.

-- 
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Article: 155908
Subject: Re: Xilinx tools for XC3020???
From: GaborSzakacs <gabor@alacron.com>
Date: Tue, 15 Oct 2013 14:57:51 -0400
Links: << >>  << T >>  << A >>
Joseph H Allen wrote:
> In article <l3i913$1af$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>> On 4/4/2013 6:20 PM, Mike Butts wrote:
>>> Hi Paul,
> 
>>> It's a plain XC3020. I installed a 2001 Student Edition on my Win7 machine, and it
>> appears to run. All it needed was the license code that came with the CD-ROM.
> 
>>> I'm pretty sure XC3020 and XC3020A differ only in timing and the same bitfile can work
>> on both. Anyway I'll be finding out sometime soon and I'll post how it goes.
>>> Thanks all!
> 
>> I take it you are on your way.  I found my old Xilinx software *and* 
>> what I think are the dongles for it, a couple three of them.  I believe 
>> the oldest version is Foundation 1.4, but I'm not sure as I seem to have 
>> left the box will it all at my other place.
> 
> I can confirm that Xilinx XACT runs on Windows-XP (with the dongle).  You
> can hand-edit your XC2064s :-)
> 
> Also, I remember that early versions of Foundation were tied to the
> partition serial number in the MBR (which you can easily change with DOS
> "debug" command).  I mean the first versions which finally got rid of the
> dongle.
> 
I've got a copy of Foundation 1.3 (this one was also called XACT Step
Foundation) on my bookshelf.  I think that 2.1 was out by the time I
actually started using Xilinx parts.  I still have ViewDraw running on
Windows XP as well as Foundation 4.1i.  I think I was running NT 4.0
when I started with Xilinx tools.  By then the oldest family I used was
the XC4000 series and very soon moved on to Spartan, SpartanXL and
Virtex.

My copy of Foundation 4.1i does not support XC3000 series, but since
there were options to include individual families when you install it
I am not sure if that means that 4.1i doesn't support XC3000 or if I
simply didn't install that in order to save some disk space at a time
when a large hard drive was 5 GB.

Since I started using Foundation, the license has been tied to the
hard drive serial number, which is easily changed, and probably
one of the reasons that Aldec sued Xilinx for delivering uncounted
seats.

The most recent Xilinx product licenses are tied to the MAC address
which can also be changed on most add-in card based Ethernet
controllers.  Xilinx is also willing to re-target your license to
a new PC, so there are many ways to cheat the seat count.

-- 
Gabor

Article: 155909
Subject: Re: reset strategy FPGA Igloo
From: rickman <gnuarm@gmail.com>
Date: Tue, 15 Oct 2013 15:40:16 -0400
Links: << >>  << T >>  << A >>
On 10/15/2013 8:34 AM, Alan Reynolds wrote:
> On 2013-10-15 01:59:34 +0000, rickman said:
>
>> On 10/14/2013 4:35 PM, alb wrote:
>>> On 13/10/2013 05:18, rickman wrote:
>>> []
>>>>> Apparently I have not found a 'global reset line' for the igloo
>>>>> family,
>>>>> but there's an interesting application note from Actel/Microsemi on
>>>>> their Flash-based devices which I find quite interesting:
>>>>>
>>>>> http://www.actel.com/documents/LPF_AC380_AN.pdf
>>>>
>>>> Wow, if Actel doesn't have a global reset line I have no idea how they
>>>> make their parts work.
>>>
>>> please do not take my words for granted. Maybe I haven't looked careful
>>> enough. OTOH I've worked with Actel components since a lot and found
>>> them very easy to handle (provided the board designer puts in a powerup
>>> reset circuitry!).
>>
>> I'm trying to understand what you *are* saying about the reset. Does
>> Actel provide a mechanism so that each FF is brought out of reset on
>> the same clock cycle? This makes a *big* difference in how you design
>> your reset operation.
>
> Non-FLASH FPGAs have to be configured on power-on so the reseting of FFs
> is a by-product of that activity which allows for the deassertion of the
> configuration RESET *after* every FF has been configured to a known
> value. Like an ASIC, Actel parts require and explicit POR because they
> do not have a configuration sequence. If the POR signal (or logic
> output) is placed on a global net and your design frequency is below
> insertion delay plus skew of the global net and the POR is synchronously
> deasserted then every FF in the chip will be in the reset state in the
> same clock cycle. Again, this is the same consideration you have to use
> when reseting an ASIC.

Thanks.  I don't need an explanation of what a Flash or RAM based FPGA 
is, I need to know what mechanism is provided in the Actel FPGAs for 
resetting all the FFs in your design on power up or external reset 
signal.  Is there *any* specific resource for this?  Or is it up to the 
synthesis tool to use the otherwise available routing?  This makes it 
sound like there are no specific features to support reset of the FFs.

I can't imagine there wouldn't be a clear explanation somewhere of how 
this is intended to be done.


>> I think you are saying the FPGA has an external reset pin which the
>> board controls. Good. Does your board control that? What does the
>> reset do on the FPGA exactly?
>>
>>
>>>> I haven't read the above app note, but the way
>>>> most brands of FPGAs work, there is a global reset line which holds the
>>>> user logic in reset until the end of config. This like is similar to a
>>>> global clock line, but without the high speed drive. When the reset is
>>>> released the entire chip can start. The problem is the delay on this
>>>> line is long enough to cause problems releasing the entire design on
>>>> the
>>>> same clock cycle.
>>>
>>> They are 'live at power up' (LAPU). See here for more information:
>>>
>>> http://www.zlgmcu.com/Microsemi/SOC/igloo/LAPU_PIB.pdf
>>>
>>> (warning: it took me a long time to download the file even though the
>>> size is relatively small - 727KB)
>>
>> I don't care if they are live at power up. Is that relevant? I'm
>> trying to understand the reset process.
>
> No configuration sequence means no global reset.

No, no configuration means no configuration.  The global reset is an 
entirely separate feature.


>>> I jumped in the project far after those details were left out of the
>>> design phase. How do you reset your logic only through the internal
>>> resources of your device?
>>
>> So are you saying there is no external reset on the board for the
>> FPGA? Why can't you add one? The need for this seems like a no-brainer
>> even if it is a white wire job.
>>
>> If there is no reset, what can you know about the state of the FFs on
>> powerup? If they are random, I don't think you can make this work
>> without a power up reset.
>>
>> Ah! I went back to your initial post about the PLL lock signal.
>> Assuming this signal is meaningful at all times I would expect it to
>> be "unlock" (as opposed to "lock") at power up. If that is true then I
>> think you can condition it to give you a reset to your logic.
>>
>> A small circuit consisting of a long period counter can be held in
>> reset while the PLL is not locked. The rest of the design is held in
>> reset by the counter. When the counter reaches its final state,
>> implying the PLL lock signal has been valid long enough to actually
>> indicate a true PLL lock, the reset to the rest of the logic is released.
>
> This is a perfectly reasonable approach and one that I have used when
> the stability of LOCK was a potential issue.

It does not resolve the issue of how the reset reaches the rest of the 
FFs in the device.  I find it hard to believe that there is no global 
reset feature in an Actel device.  This means the general routing or 
possibly clock routing must be used.


>> Maybe this is obvious to you. If so, I don't understand what your
>> question is.
>>
>> To tell you the truth, I would try discussing this with an Actel FAE.
>> Hopefully they know the answer.

I remember when FAEs used to respond to posts here.  But then some of 
them generated some rather bad press for their company with a rather 
confrontational style.

-- 

Rick

Article: 155910
Subject: Re: Xilinx tools for XC3020???
From: rickman <gnuarm@gmail.com>
Date: Tue, 15 Oct 2013 16:57:27 -0400
Links: << >>  << T >>  << A >>
On 10/15/2013 2:57 PM, GaborSzakacs wrote:
>
> The most recent Xilinx product licenses are tied to the MAC address
> which can also be changed on most add-in card based Ethernet
> controllers. Xilinx is also willing to re-target your license to
> a new PC, so there are many ways to cheat the seat count.

I am a one man company, so I never have incentive to "cheat the seat 
count".  But this thread is exactly the issue I am concerned about with 
licensed software.  Will it be supported some years down the road when I 
need it for an update?  If it were FOSS, I would know the answer.  But 
so far I have found commercial software to be tied to the bucks it can 
generate for the developers in the future, not the bucks you have paid 
in the past.

This is the one reason I can see in favor of pushing for FOSS FPGA 
software.  But unfortunately the ones pushing are a very small force 
compared to the overall market so that they have *no* influence in the 
direction of FPGA development software... at least in terms of being 
supported by the FPGA vendors.

-- 

Rick

Article: 155911
Subject: Re: Lattice Diamond & tristate
From: Aleksandar Kuktin <akuktin@gmail.com>
Date: Wed, 16 Oct 2013 00:43:57 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Sat, 05 Oct 2013 04:23:27 +0000, Joseph H Allen wrote:

>>Hmm... I'm pretty sure this won't work. The synthesizer will again
>>complain that the wire is driven from multiple sources. But I'll give it
>>a try.
> 
> I just tried it in LSE- it works fine.  Also it tri-state works.  Make
> sure you are assigning like this:
> 
> assign bus = enable ? signal : 4'bzzzz;
> 
> It also works to have module outputs connected directly to a wor or
> tri-state bus.  Annoyingly, this does not work in Altera Quartus-II.

I've only now found time to try this. And it works! What happened 
previously was that I assigned like this:

assign bus = enable ? signal : 8'hz;

Turns out you _do_ need to 'z every bit.

Unfortunately, the bidir bus did not live up to my expectations. 
Basically, yes, it reduces the number of SLICEs used, but only marginally 
and not always, depending on other details (like the one below).

I found a different way to free up space: use the internal clock. MachXO2 
comes with an internal oscillator and using this instead of an other 
clock source can easily slash high tens of SLICEs off. I don't know 
exactly why this happens, the only thing I can assume is that many of 
those SLICEs are used for synchronization or normalization or something 
else that doesn't need to be done with the onboard clock.

Article: 155912
Subject: Re: Lattice Diamond & tristate
From: Gabor <gabor@szakacs.org>
Date: Tue, 15 Oct 2013 22:10:14 -0400
Links: << >>  << T >>  << A >>
On 10/15/2013 8:43 PM, Aleksandar Kuktin wrote:
> On Sat, 05 Oct 2013 04:23:27 +0000, Joseph H Allen wrote:
>
>>> Hmm... I'm pretty sure this won't work. The synthesizer will again
>>> complain that the wire is driven from multiple sources. But I'll give it
>>> a try.
>>
>> I just tried it in LSE- it works fine.  Also it tri-state works.  Make
>> sure you are assigning like this:
>>
>> assign bus = enable ? signal : 4'bzzzz;
>>
>> It also works to have module outputs connected directly to a wor or
>> tri-state bus.  Annoyingly, this does not work in Altera Quartus-II.
>
> I've only now found time to try this. And it works! What happened
> previously was that I assigned like this:
>
> assign bus = enable ? signal : 8'hz;
>
> Turns out you _do_ need to 'z every bit.

Generally I don't use hexadecimal for tristates.  I have always found
that 8'bz is the same as 8'bzzzzzzzz.  Remember that if you size the
tristate constant too small (e.g. 4'bz for an 8-bit reg) then it
gets _zero_ extended as required by the LRM.

>
> Unfortunately, the bidir bus did not live up to my expectations.
> Basically, yes, it reduces the number of SLICEs used, but only marginally
> and not always, depending on other details (like the one below).
>
> I found a different way to free up space: use the internal clock. MachXO2
> comes with an internal oscillator and using this instead of an other
> clock source can easily slash high tens of SLICEs off. I don't know
> exactly why this happens, the only thing I can assume is that many of
> those SLICEs are used for synchronization or normalization or something
> else that doesn't need to be done with the onboard clock.
>

huh?  I would have thought that the slice usage would be the same
for any clock source.  You might use some slices for reset and
lock detection if you add a PLL for the external clock.  But just
running a pin to a global clock buffer shouldn't use any slice
resources.  That being said, I've seen large differences in slice
usage for the exact same design built with different placements.
Much of this is due to LUTs used as route-throughs or differences
in slice packing.  I'd check the LUT and register count rather
than slices before giving any credence to the idea that an external
clock source adds to logic usage.

-- 
Gabor

Article: 155913
Subject: Re: Lattice Diamond & tristate
From: rickman <gnuarm@gmail.com>
Date: Tue, 15 Oct 2013 23:55:21 -0400
Links: << >>  << T >>  << A >>
On 10/15/2013 10:10 PM, Gabor wrote:
> On 10/15/2013 8:43 PM, Aleksandar Kuktin wrote:
>>
>> Unfortunately, the bidir bus did not live up to my expectations.
>> Basically, yes, it reduces the number of SLICEs used, but only marginally
>> and not always, depending on other details (like the one below).
>>
>> I found a different way to free up space: use the internal clock. MachXO2
>> comes with an internal oscillator and using this instead of an other
>> clock source can easily slash high tens of SLICEs off. I don't know
>> exactly why this happens, the only thing I can assume is that many of
>> those SLICEs are used for synchronization or normalization or something
>> else that doesn't need to be done with the onboard clock.
>>
>
> huh? I would have thought that the slice usage would be the same
> for any clock source. You might use some slices for reset and
> lock detection if you add a PLL for the external clock. But just
> running a pin to a global clock buffer shouldn't use any slice
> resources. That being said, I've seen large differences in slice
> usage for the exact same design built with different placements.
> Much of this is due to LUTs used as route-throughs or differences
> in slice packing. I'd check the LUT and register count rather
> than slices before giving any credence to the idea that an external
> clock source adds to logic usage.

This whole thread is a bit silly.  There are *no* internal tristates in 
FPGAs released in the last 10 years, possibly 15 years.  The simulator 
is showing tristates because that is what the code describes.  Synthesis 
is turning this into multiplexers inside the FPGA.

I can't say anything about the "slice" usage because slices are not the 
primitive elements in even a Xilinx FPGA, rather slices have multiple 
components which all get used in different ways including just for 
routing.  If any part of a slice is used the slice is counted as used. 
This doesn't mean more logic can't be included... in other words, the 
slice utilization could be as high as 100% and you can still add more 
logic to your design.

So counting slice usage isn't really telling you the story you want to 
know about.  Try looking at the synthesis tool.  Often they give a 
schematic view of exactly what logic was generated.  I believe this is 
called "Technology View" in the tool I use for Lattice parts.  Then you 
can see exactly how they are implementing your HDL code.

Personally I would prefer to code for multiplexers because then you have 
some control over how it is implemented.  In some logic devices other 
than Xilinx, muxes are more efficiently implemented as the cascaded AND 
of ORs rather than the traditional OR of ANDs, product of sums vs. sum 
of products if you will.  Coding to the hardware can help the tool get 
to an efficient solution, but not if you are imagining internal logic 
that doesn't exist.

-- 

Rick

Article: 155914
Subject: Re: Xilinx tools for XC3020???
From: Sean Durkin <news_MONTH@tuxroot.de>
Date: Wed, 16 Oct 2013 09:33:14 +0200
Links: << >>  << T >>  << A >>
rickman wrote:
> I am a one man company, so I never have incentive to "cheat the seat
> count".  But this thread is exactly the issue I am concerned about with
> licensed software.  Will it be supported some years down the road when I
> need it for an update?
I think this problem has been simplified by the advancements in 
virtualization in recent years. At the company where I used to work, we 
had virtual machines with old Windows releases and old tools versions, 
and someone was clever enough to migrate the licenses for the old tools 
to those VMs before it was too late. The VMs themselves you can just 
copy from one PC to another if you upgrade your hardware. They had some 
issues with old parallel port dongles (since which PC has a parallel 
port nowadays?), but there's add-pon cards for that. So at least there's 
a working version of all the tools needed for older projects.

> This is the one reason I can see in favor of pushing for FOSS FPGA
> software.  But unfortunately the ones pushing are a very small force
> compared to the overall market so that they have *no* influence in the
> direction of FPGA development software... at least in terms of being
> supported by the FPGA vendors.
Exactly. I personally don't think this is ever going to go anywhere. 
Even if there was enough manpower to design a decent toolset from the 
ground up (which there isn't, since the people who have the capabilities 
and know-how usually work for one of the vendors), vendors would have to 
disclose too many architecture internals and such, which is not going to 
happen (maybe they'd release that info for FPGA families that have been 
out of production for years but not current ones).

I can imagine a University putting something together, but something 
like that usually stays at the 0.0011alpha release state forever once 
the PhDs it's based on are finished.

In general, for a project this size and type FOSS rarely works, IMHO. It 
can work if the community can get an existing code base and improve it 
(like it happened for Mozilla and OpenOffice), but not if it's to be a 
project of this size and started from the ground up. Especially if it's 
something that doesn't "interest" a lot of people. After all, this is a 
niche (compared to something like the Gimp which potentially has 
millions and millions of users), so there's just not that many people 
likely to participate in the first place. This wouldn't be something 
that everyone(TM) uses, and it's way too big for a single person or 
small group of people to make any useful progress.

So, no, I don't think OS EDA tools are ever going to happen. At least 
not something really useful... Unless one of the vendors decides to 
release the source code for their tools. But why should they?

CU,
Sean

Article: 155915
Subject: Re: draw lines, circles, squares on FPGA by mouse and display on VGA
From: ajbhavana89@gmail.com
Date: Wed, 16 Oct 2013 00:39:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, 2 November 2011 17:25:33 UTC+10, lexuancong  wrote:
> hi !
> 
> im from vietnam . my english is not good , i hope you can understand
> 
> what i say . thanks !
> 
> i have project to graduate university .
> 
> my project is draw circle , line , triagle in FPGA , display on VGA
> 
> ( only use verilog , don't use C) . i have many problems , and time is
> 
> running out . if you have data , code about it , please help me.
> 
> ....
> 
> thanks you so much !

Hi I am in the same situation with the same project. can u please help me

Article: 155916
Subject: Re: reset strategy FPGA Igloo
From: alb <alessandro.basili@cern.ch>
Date: Wed, 16 Oct 2013 10:02:05 +0200
Links: << >>  << T >>  << A >>
Hi Rick,

On 15/10/2013 03:59, rickman wrote:
[]
>>> Wow, if Actel doesn't have a global reset line I have no idea how they
>>> make their parts work.
>> please do not take my words for granted. Maybe I haven't looked careful
>> enough. OTOH I've worked with Actel components since a lot and found
>> them very easy to handle (provided the board designer puts in a powerup
>> reset circuitry!).
> 
> I'm trying to understand what you *are* saying about the reset.  Does
> Actel provide a mechanism so that each FF is brought out of reset on the
> same clock cycle?  This makes a *big* difference in how you design your
> reset operation.

No. You need to take care of it on your own, externally (with dedicated
circuitry) and internally (with dedicated logic).

> I think you are saying the FPGA has an external reset pin which the
> board controls.  Good.  Does your board control that?  What does the
> reset do on the FPGA exactly?

In the design I'm working on there's no external reset circuitry on the
pcb and no pin is reserved for this purpose except for an 'init' pin
which can be activated upon certain conditions which, as of now, do not
include power on.

I've not yet found any dedicated pin and/or buffer to route the reset in
the IGLOO family.

>>> I haven't read the above app note, but the way
>>> most brands of FPGAs work, there is a global reset line which holds the
>>> user logic in reset until the end of config.  This like is similar to a
>>> global clock line, but without the high speed drive.  When the reset is
>>> released the entire chip can start.  The problem is the delay on this
>>> line is long enough to cause problems releasing the entire design on the
>>> same clock cycle.
>>
>> They are 'live at power up' (LAPU). See here for more information:
>>
>> http://www.zlgmcu.com/Microsemi/SOC/igloo/LAPU_PIB.pdf
>>
>> (warning: it took me a long time to download the file even though the
>> size is relatively small - 727KB)
> 
> I don't care if they are live at power up.  Is that relevant?  I'm
> trying to understand the reset process.

I mentioned the 'live at power up' feature to refer to the fact that
they *do not need* a configuration.

>>> It is seldom that an entire FPGA design has to start on the same clock
>>> edge.  I design individual circuits to start up on a local copy of the
>>> reset.  Or better still is to design them so they start in an idle state
>>> waiting for something else to happen which will take a clock cycle or
>>> two providing enough delay that they don't need a synchronous reset.
>>
>> I agree with what Alan says: "Designing for all-IDLE FSMs is the proper
>> approach but doesn't eliminate the need to have an explicit reset"
> 
> Maybe I don't understand what you are saying at all.  Hopefully you will
> explain exactly what the problem is.  Is there *no* reset to the FPGA on
> your board?

Correct, there's *no* reset to the FPGA on my board.

[]
>> I jumped in the project far after those details were left out of the
>> design phase. How do you reset your logic only through the internal
>> resources of your device?
> 
> So are you saying there is no external reset on the board for the FPGA?
>  Why can't you add one?  The need for this seems like a no-brainer even
> if it is a white wire job.

A white wire job will not help you since you need at least an RC
pulled-up to Vcc and C might be the equivalent of 4 caps (a series of
two parallel ones) to avoid single point failure and hold the FPGA in
reset state permanently upon a short fault on the cap.

Besides, we are about to enter flight module production (it's a space
application) and we cannot functionally deviate from the qualification
module (at least this are the rules we have to follow).

> If there is no reset, what can you know about the state of the FFs on
> powerup?  If they are random, I don't think you can make this work
> without a power up reset.

In the AN I posted there's a solution the vendor proposes to implement a
POR. They suggest to rely on an external weak pull-up and profit of the
different time for input/output configuration during a power-up
sequence. I do not have an external pull-up, but I/Os can be opted with
a weak pull-up and maybe the result is the same.

[]
> A small circuit consisting of a long period counter can be held in reset
> while the PLL is not locked.  The rest of the design is held in reset by
> the counter.  When the counter reaches its final state, implying the PLL
> lock signal has been valid long enough to actually indicate a true PLL
> lock, the reset to the rest of the logic is released.

I'll set the counter to count the maximum lock time as specified in the
datasheet and I should be good to go. Synchronous release of the reset
line should make it simple to perform STA on the reset line and let the
P&R meet the time constraints.

> Maybe this is obvious to you.  If so, I don't understand what your
> question is.

In the OP, I was asking whether I should route the reset signal
(currently coming from the 'lock' signal on the pll) to a special global
net to avoid timing issues. After my post, Mark pointed out how
unreliable are 'lock' signals from PLL and hence the whole discussion.

> To tell you the truth, I would try discussing this with an Actel FAE.
> Hopefully they know the answer.

That is a valid suggestion, I used to believe that places like this one
would have been good ones to get an answer from an FAE, <rant mode on>
but it seems those days are gone and companies tend to continue to lock
in users within their closed circles <rant mode off>.


Article: 155917
Subject: Re: xilinx spi example under linux
From: orly.bialer@me.com
Date: Wed, 16 Oct 2013 01:11:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, January 3, 2007 9:20:30 PM UTC+2, Clark Pope wrote:
> Does anyone have any example code that uses the Xilinx SPI Linux driver? I
> just need to read a temperature sensor so something simple that opens the
> device and does read and writes should work.
> 
> Thanks,
> Clark

Hi
Is there anyway you can post the example?

Thanks

Article: 155918
Subject: Re: Xilinx tools for XC3020???
From: rickman <gnuarm@gmail.com>
Date: Wed, 16 Oct 2013 04:15:33 -0400
Links: << >>  << T >>  << A >>
On 10/16/2013 3:33 AM, Sean Durkin wrote:
> rickman wrote:
>> I am a one man company, so I never have incentive to "cheat the seat
>> count". But this thread is exactly the issue I am concerned about with
>> licensed software. Will it be supported some years down the road when I
>> need it for an update?
> I think this problem has been simplified by the advancements in
> virtualization in recent years. At the company where I used to work, we
> had virtual machines with old Windows releases and old tools versions,
> and someone was clever enough to migrate the licenses for the old tools
> to those VMs before it was too late. The VMs themselves you can just
> copy from one PC to another if you upgrade your hardware. They had some
> issues with old parallel port dongles (since which PC has a parallel
> port nowadays?), but there's add-pon cards for that. So at least there's
> a working version of all the tools needed for older projects.

You are talking about one particular licensing scheme for one, very old 
product.  The licenses used on newer software work off of a software key 
that is tied to some aspect of your PC but more importantly, must be 
renewed each year regardless.  If they stop renewing the license, you 
are stuck.


>> This is the one reason I can see in favor of pushing for FOSS FPGA
>> software. But unfortunately the ones pushing are a very small force
>> compared to the overall market so that they have *no* influence in the
>> direction of FPGA development software... at least in terms of being
>> supported by the FPGA vendors.
> Exactly. I personally don't think this is ever going to go anywhere.
> Even if there was enough manpower to design a decent toolset from the
> ground up (which there isn't, since the people who have the capabilities
> and know-how usually work for one of the vendors), vendors would have to
> disclose too many architecture internals and such, which is not going to
> happen (maybe they'd release that info for FPGA families that have been
> out of production for years but not current ones).

It is *not* a matter of designing a *decent* toolset.  The problem is 
the FPGA vendors don't release the information required to use their 
devices without their proprietary software.  You simply *can't* roll 
your own FPGA development package end to end.  It would be like writing 
a compiler for a CPU with no info on the instruction set.


> I can imagine a University putting something together, but something
> like that usually stays at the 0.0011alpha release state forever once
> the PhDs it's based on are finished.

There *are* FOSS HDL synthesis and simulation tools.  I don't know, but 
I doubt there are FOSS place and route tools or timing analysis.  The 
part that you just can't do without a *huge* reverse engineering effort 
is generating the bit stream file.


> In general, for a project this size and type FOSS rarely works, IMHO. It
> can work if the community can get an existing code base and improve it
> (like it happened for Mozilla and OpenOffice), but not if it's to be a
> project of this size and started from the ground up. Especially if it's
> something that doesn't "interest" a lot of people. After all, this is a
> niche (compared to something like the Gimp which potentially has
> millions and millions of users), so there's just not that many people
> likely to participate in the first place. This wouldn't be something
> that everyone(TM) uses, and it's way too big for a single person or
> small group of people to make any useful progress.
>
> So, no, I don't think OS EDA tools are ever going to happen. At least
> not something really useful... Unless one of the vendors decides to
> release the source code for their tools. But why should they?

*That's* a bit extreme.  There are ***tons*** of FOSS EDA tools 
available, as I mentioned, even HDL tools.  It is just the final part 
that requires intimate knowledge of the chips that is not so feasible to 
develop.


-- 

Rick

Article: 155919
Subject: Re: reset strategy FPGA Igloo
From: rickman <gnuarm@gmail.com>
Date: Wed, 16 Oct 2013 04:29:59 -0400
Links: << >>  << T >>  << A >>
On 10/16/2013 4:02 AM, alb wrote:
> Hi Rick,
>
> On 15/10/2013 03:59, rickman wrote:
> []
>>>> Wow, if Actel doesn't have a global reset line I have no idea how they
>>>> make their parts work.
>>> please do not take my words for granted. Maybe I haven't looked careful
>>> enough. OTOH I've worked with Actel components since a lot and found
>>> them very easy to handle (provided the board designer puts in a powerup
>>> reset circuitry!).
>>
>> I'm trying to understand what you *are* saying about the reset.  Does
>> Actel provide a mechanism so that each FF is brought out of reset on the
>> same clock cycle?  This makes a *big* difference in how you design your
>> reset operation.
>
> No. You need to take care of it on your own, externally (with dedicated
> circuitry) and internally (with dedicated logic).
>
>> I think you are saying the FPGA has an external reset pin which the
>> board controls.  Good.  Does your board control that?  What does the
>> reset do on the FPGA exactly?
>
> In the design I'm working on there's no external reset circuitry on the
> pcb and no pin is reserved for this purpose except for an 'init' pin
> which can be activated upon certain conditions which, as of now, do not
> include power on.
>
> I've not yet found any dedicated pin and/or buffer to route the reset in
> the IGLOO family.
>
>>>> I haven't read the above app note, but the way
>>>> most brands of FPGAs work, there is a global reset line which holds the
>>>> user logic in reset until the end of config.  This like is similar to a
>>>> global clock line, but without the high speed drive.  When the reset is
>>>> released the entire chip can start.  The problem is the delay on this
>>>> line is long enough to cause problems releasing the entire design on the
>>>> same clock cycle.
>>>
>>> They are 'live at power up' (LAPU). See here for more information:
>>>
>>> http://www.zlgmcu.com/Microsemi/SOC/igloo/LAPU_PIB.pdf
>>>
>>> (warning: it took me a long time to download the file even though the
>>> size is relatively small - 727KB)
>>
>> I don't care if they are live at power up.  Is that relevant?  I'm
>> trying to understand the reset process.
>
> I mentioned the 'live at power up' feature to refer to the fact that
> they *do not need* a configuration.
>
>>>> It is seldom that an entire FPGA design has to start on the same clock
>>>> edge.  I design individual circuits to start up on a local copy of the
>>>> reset.  Or better still is to design them so they start in an idle state
>>>> waiting for something else to happen which will take a clock cycle or
>>>> two providing enough delay that they don't need a synchronous reset.
>>>
>>> I agree with what Alan says: "Designing for all-IDLE FSMs is the proper
>>> approach but doesn't eliminate the need to have an explicit reset"
>>
>> Maybe I don't understand what you are saying at all.  Hopefully you will
>> explain exactly what the problem is.  Is there *no* reset to the FPGA on
>> your board?
>
> Correct, there's *no* reset to the FPGA on my board.
>
> []
>>> I jumped in the project far after those details were left out of the
>>> design phase. How do you reset your logic only through the internal
>>> resources of your device?
>>
>> So are you saying there is no external reset on the board for the FPGA?
>>   Why can't you add one?  The need for this seems like a no-brainer even
>> if it is a white wire job.
>
> A white wire job will not help you since you need at least an RC
> pulled-up to Vcc and C might be the equivalent of 4 caps (a series of
> two parallel ones) to avoid single point failure and hold the FPGA in
> reset state permanently upon a short fault on the cap.
>
> Besides, we are about to enter flight module production (it's a space
> application) and we cannot functionally deviate from the qualification
> module (at least this are the rules we have to follow).
>
>> If there is no reset, what can you know about the state of the FFs on
>> powerup?  If they are random, I don't think you can make this work
>> without a power up reset.
>
> In the AN I posted there's a solution the vendor proposes to implement a
> POR. They suggest to rely on an external weak pull-up and profit of the
> different time for input/output configuration during a power-up
> sequence. I do not have an external pull-up, but I/Os can be opted with
> a weak pull-up and maybe the result is the same.
>
> []
>> A small circuit consisting of a long period counter can be held in reset
>> while the PLL is not locked.  The rest of the design is held in reset by
>> the counter.  When the counter reaches its final state, implying the PLL
>> lock signal has been valid long enough to actually indicate a true PLL
>> lock, the reset to the rest of the logic is released.
>
> I'll set the counter to count the maximum lock time as specified in the
> datasheet and I should be good to go. Synchronous release of the reset
> line should make it simple to perform STA on the reset line and let the
> P&R meet the time constraints.
>
>> Maybe this is obvious to you.  If so, I don't understand what your
>> question is.
>
> In the OP, I was asking whether I should route the reset signal
> (currently coming from the 'lock' signal on the pll) to a special global
> net to avoid timing issues. After my post, Mark pointed out how
> unreliable are 'lock' signals from PLL and hence the whole discussion.
>
>> To tell you the truth, I would try discussing this with an Actel FAE.
>> Hopefully they know the answer.
>
> That is a valid suggestion, I used to believe that places like this one
> would have been good ones to get an answer from an FAE,<rant mode on>
> but it seems those days are gone and companies tend to continue to lock
> in users within their closed circles<rant mode off>.

Ok, I think I understand the problem now.  The fact that you are working 
on a space application makes it more clear why you are using an Actel 
part.  I think space applications are what kept Actel alive for so many 
years.

So you have a poor hardware design that you can't change and you are 
looking for some trick within the FPGA to generate a power on reset. 
I'm still not clear on why you can't use the PLL lock signal with 
conditioning.  If the PLL lock signal is deasserted at power on, there 
is your power on reset.  Then you simply need to condition it well 
enough to properly control exit from reset reliably.

Am I still missing something?

-- 

Rick

Article: 155920
Subject: Re: draw lines, circles, squares on FPGA by mouse and display on
From: Herbert Kleebauer <klee@unibwm.de>
Date: Wed, 16 Oct 2013 13:10:00 +0200
Links: << >>  << T >>  << A >>
On 16.10.2013 09:39, ajbhavana89@gmail.com wrote:

>> i have project to graduate university .
>> my project is draw circle , line , triagle in FPGA , display on VGA
>> ( only use verilog , don't use C) . i have many problems , and time is
>> running out . if you have data , code about it , please help me.

> Hi I am in the same situation with the same project. can u please help me

Implement a simple CPU on the FPGA and do the drawing
in software.




Article: 155921
Subject: Zynq devices, boards and suppliers
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Wed, 16 Oct 2013 12:28:44 +0100
Links: << >>  << T >>  << A >>
I'd like to pick people's brains about aspects of
different *suppliers* of Zynq boards. Avnet and Digilent
are front-runners, but any info/opinions about other
suppliers would be helpful too.

   - ease of using their embedded linux. My needs
     are simple, requiring a shell and TCP/IP protocols
     over ethernet. GUI not required, but might be
     used if it didn't complicate the development.

   - quality of online support. How easy is it
     likely to be to find the information so that
     I can (a) duplicate any supplied demo environment
     and (b) mutate it so that my code accesses my
     programmable logic

   - board production longevity. I'm not concerned
     about decades, but I would be concerned if a
     board was unobtainable within months

   - ISE or Vivado environment

Background and context...

I'm intending to develop something based around a small
Xylinx Zynq device. Cost is an issue, but not to the
extent that I will be developing a board containing
the FPGA itself. I will, however, be developing a small
simple add-on board containing my analogue circuits.

Now I can read a datasheet and schematic and outline
to determine the extent to which a board is suitable.
However, as we are all aware, those documents /don't/
cover all the important points when choosing a board!

I've created many stand-alone hardware and software
embedded systems, but *not* based on linux *nor* on ARM
*nor* in the Xilinx ecosystem. Since Zynq devices
represent a complex environment, I'll have a learning
curve (good, I like challenges), and I'm interested
in the quality of the resources and support that
I'll need to overcome my misapprehensions.

Article: 155922
Subject: Re: Zynq devices, boards and suppliers
From: Frank Buss <fb@frank-buss.de>
Date: Wed, 16 Oct 2013 13:56:04 +0200
Links: << >>  << T >>  << A >>
Tom Gardner wrote:
> I'd like to pick people's brains about aspects of
> different *suppliers* of Zynq boards. Avnet and Digilent
> are front-runners, but any info/opinions about other
> suppliers would be helpful too.

If you don't need it now, you might take a look at the Parallella board:

http://www.parallella.org

Currently they have some issues with EOL parts and re-designing parts of
the board, so it will be delayed a bit. But I guess there are not much
boards with the Zynq chip for $99, and you get a lot of peripherals,
too, and of course the Epiphany coprocessor. And the Zynq chip used on
the Parallella board is supported by the free Xilinx ISE version:

http://forums.parallella.org/viewtopic.php?f=23&t=134

Linux is already working for the board (Ubuntu, well, you can't have
anything, but should be not too difficult to port Debian for it). Even
if you don't use it for your project later, might be a good starting
point to learn to program the Zynq.

-- 
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

Article: 155923
Subject: Re: Xilinx tools for XC3020???
From: Sean Durkin <news_MONTH@tuxroot.de>
Date: Wed, 16 Oct 2013 14:17:06 +0200
Links: << >>  << T >>  << A >>
rickman wrote:
> You are talking about one particular licensing scheme for one, very old
> product.  The licenses used on newer software work off of a software key
> that is tied to some aspect of your PC but more importantly, must be
> renewed each year regardless.  If they stop renewing the license, you
> are stuck.
You are right about that. But in all the cases I am familiar with you 
could switch to perpetual licenses when support was dropped (which you 
were informed of in a timely manner). The main problem was then having a 
machine the tools still run on.

> It is *not* a matter of designing a *decent* toolset.  The problem is
> the FPGA vendors don't release the information required to use their
> devices without their proprietary software.  You simply *can't* roll
> your own FPGA development package end to end.  It would be like writing
> a compiler for a CPU with no info on the instruction set.
That is what I was saying. Still there's more to writing a USABLE 
toolset than just having the necessary information. I doubt that even if 
Xilinx would release all the specs, we'd ever get a DECENT, usable FOSS 
toolset. That kind of complex work requires coordinated effort, 
something that obviously not even the vendors with dedicated, big 
development teams can muster, let alone keep up to date with the 
ever-evolving chip technology. That is not the kind of project suitable 
to the OSS "community"-based design flow (there's exceptions, see below).

> There *are* FOSS HDL synthesis and simulation tools.  I don't know, but
> I doubt there are FOSS place and route tools or timing analysis.  The
> part that you just can't do without a *huge* reverse engineering effort
> is generating the bit stream file.
Not that I'm aware of, except maybe some highly experimental stuff based 
on obsolete parts. In other words: useless, except for academic fiddling.

> *That's* a bit extreme.  There are ***tons*** of FOSS EDA tools
> available, as I mentioned, even HDL tools.
And that's exactly the problem. Tons of different tools, but nothing 
that is really useful (well, ghdl maybe... and if you wanna count Emacs 
VHDL mode as an EDA tool...).
IMHO that's a general problem of FOSS. You can find some tool for almost 
EVERYTHING, but usually it stays in the state where it does exactly what 
the person who started it needed at one point, but nothing else. Then 
another person, who isn't content with what's available, starts another 
project, and so on. In the end you have a dozen tools that satisfy the 
needs of their respective creators, but are more or less useless to the 
rest of humankind. So if you don't have the time or know-how to improve 
the tools yourself, you're screwed. But you can't complain, since you 
can't look a gift hourse in the mouth...

I've been using Linux for 15 years, and of course a lot of FOSS, and 
there's wonderful software out there far surpassing anything 
commercially available. But IMHO OSS really only works well in these cases:
1. small tools that can be handled by one enthusiastic person or a small 
group of people in their spare time
2. tools/services that big companies are pushing (like Red Hat or 
Google), meaning they put a decent-sized development team on it and pay 
it to work on that
3. projects that are based on an existing commercial product's source 
code (see OpenOffice and the like), or were developed commercially and 
then released to the public for whatever reason
4. projects that have many, many (potential) users and a lot of paid 
professional people chipping in (like the Linux kernel, the GCC suite, 
Gnome or KDE)

EDA tools fit NONE of the above.

And in cases like that you typically end up with tons of half-baked 
tools. As long as vendors provide free licenses for their tools at least 
for hobbyist use, there's really no incentive for hobbyists to invest 
their time and work in FOSS EDA tools. I'm saying hobbyists, since the 
pros work for one of the vendors anyway and/or don't have the need for 
FOSS because they have licenses for the commercial tools. And all of 
this applies even if all the required information was available, which 
it is not. On projects like that you never seem to see any real 
progress, because a) there's not enough manpower, b) there's not enough 
incentive and c) they soon hit the wall where they can't get the 
information they need.

You are of course right that it would be nice to have FOSS tools to rely 
on for eternity, but as you said the number of people really needing 
that is small, way too small to get anything accomplished, really. So 
I'm sticking with what I said before: I don't see it happening, ever. 
Not for a toolchain for the complete flow, and one that goes beyond 
cryptic command-line tools that work in only 30% of applications.

cu,
Sean

Article: 155924
Subject: Re: reset strategy FPGA Igloo
From: alb <alessandro.basili@cern.ch>
Date: Wed, 16 Oct 2013 17:21:38 +0200
Links: << >>  << T >>  << A >>
Hi Rick,

On 16/10/2013 10:29, rickman wrote:
[]
> Ok, I think I understand the problem now.  The fact that you are working
> on a space application makes it more clear why you are using an Actel
> part.  I think space applications are what kept Actel alive for so many
> years.

and automotive, avionics, defense, just to mention a few more.

> So you have a poor hardware design that you can't change and you are
> looking for some trick within the FPGA to generate a power on reset. 

correct.

> I'm
> still not clear on why you can't use the PLL lock signal with
> conditioning.  If the PLL lock signal is deasserted at power on, there
> is your power on reset.  Then you simply need to condition it well
> enough to properly control exit from reset reliably.
> 
> Am I still missing something?

Maybe you missed what I wrote in my previous post in reply to your
suggestion, so I'll paste it here for your convenience:

> I'll set the counter to count the maximum lock time as specified in the
> datasheet and I should be good to go. Synchronous release of the reset
> line should make it simple to perform STA on the reset line and let the
> P&R meet the time constraints.

Exactly as you proposed but specifying the length of the counter.

Indeed there's even a more subtle detail to add: since I do not know
what is the state of the lock signal at power up, my counter should have
a fixed value at reset and start to count when lock signal is deasserted
if and only if the fixed value of the counter is present. In this way I
can guarantee that a lock signal which is undefined at the beginning
does not allow the counter to start from a random position and hit the
target value too early. Something along these lines:

<code: not tested!>
-- rst is the lock signal from PLL
process (clk, rst)
  if rst = '0' then
    counter <= "101001000000";  -- 6 bit counter + 6 bit check
    global_rst <= '0';          -- active low reset
  elsif rising_edge(clk) then
    if counter (11 downto 6) = "101001" then
      counter <= counter + 1;
    elsif counter (6) = '0' then
      global_rst <= '1';
    end if;
  end if;
end process;
</code>

I'm not sure the synthesis will prune the upper end of the bits, so I
might need to do something more clever, but the upper part of the
counter is to verify that it did have a proper reset signal at some point.



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