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
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 156050

Article: 156050
Subject: Re: Qsys and clock crossings
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Wed, 13 Nov 2013 09:15:02 -0800
Links: << >>  << T >>  << A >>
On 13 Nov 2013 09:53:53 +0000 (GMT)
Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:

> Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:
> > Well, now I know why I'm getting old junk transactions stuck in my
> > clock crossing bridge after resetting one side.  Does anyone have a
> > reason why one might want to reset only one side or the other of the
> > FIFO, or is this (undocumented, of course) behavior just silly? 
> 
> I'm not completely clear on why that happens.  You need two inputs because
> each reset needs to be in the right clock domain, otherwise Excitement (TM)
> happens if you try and clock domain cross with the resets.  Perhaps the
> model is that the resets only reset the parts in the domain that belongs to
> it, and propagating the resets is your problem.
> 
> How are you generating the clocks for the two parts? I think the standard
> Qsys clock input block will also synchronise a reset to a given clock
> - perhaps you need one of those?
> 
> Theo

And yet the entire point of the core is clock domain crossing, so they
should have had the resets cross and resynchronize as well.  A
halfway-reset FIFO is a broken FIFO.

The clocks/resets for the two parts are entirely independent.  One is
the 125 MHz clock that comes out of the PCIe core (which at least
on Arria II can't be PLL'd like a real clock).  The other is my own
free-running 125 MHz clock. My system is a multi-mastered bus in which
PCIe is one of the possible masters.  The main logic has to all run
from the free-running clock since PCIe availability isn't required for
operation of the rest of the world.

The solution I used was to tie both resets to both sides of the
clock crossing bridge.  This forces Qsys to generate reset adapters on
both sides that OR the two resets and synchronize the deasserting edge
to the respective clock.  But if you just rely on Qsys to automatically
add your clock crossings, it won't do that.  Hence, if you do have two
independent reset domains, it'll wreck the FIFO.

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

Article: 156051
Subject: Re: Zynq devices, boards and suppliers
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Wed, 13 Nov 2013 23:55:03 +0000
Links: << >>  << T >>  << A >>
On 11/11/13 23:22, Mike Ng wrote:
> On Monday, November 11, 2013 4:28:24 AM UTC-5, Tom Gardner wrote:
>> Out of curiosity, how long ago did you buy them and how long did
>> they take to materialise? Currently Avnet are showing no stock
>> and 5 weeks lead time.
>>
>> Worryingly, it has been "5 weeks" for the past 3 weeks - so I'm
>> concerned that Avnet have "lost interest" in the board. Any info
>> about Avnet's support practices would be useful.
>
> I ordered one mid-September when the leadtime was "1 week". That sounded a little suspicious so I went to web chat support and got "4 weeks" as the real leadtime.
>
> It does sound like they're preparing a new rev.

Or maybe they're preparing something much more expensive...
http://linuxgizmos.com/tiny-arm-plus-fpga-sbc-gains-beefier-fpga/


Article: 156052
Subject: Re: reset strategy FPGA Igloo
From: rickman <gnuarm@gmail.com>
Date: Wed, 13 Nov 2013 20:10:53 -0500
Links: << >>  << T >>  << A >>
On 11/13/2013 6:43 AM, alb wrote:
> Hi Rick,
>
> On 08/11/2013 15:47, rickman wrote:
> []
>>> According to the FAE it is possible to configure the internal weak
>>> pull-up resistor on the PIN configuration and profit of the same
>>> mechanism described in the AN I was referring to
>>> (http://www.actel.com/documents/LPF_AC380_AN.pdf), therefore
>>> *without* the need of an additional external pull up resistor.
>>
>> The app note goes into great detail about the timing of VCC and VCCI.
>> In this discussion I believe they are talking about the input from
>> the IBUF (RST_p) when they say, "The I/Os are tristated and the core
>> logic detects '1' on the inputs from the boundary scan register
>> (BSR)."  It is not clear what sets the value in the BSR.  It is also
>> not clear how this determines the value of the RST_p signal.
>
> Between the I/O Bank and the FPGA core there's the BSR mandated by the
> IEEE-1149.1 standard (JTAG) that you can control during programming. I'm
> trying to look for 'default' values, but that is not essential since
> when both VCC and VCCI will be above the functional voltage level the
> I/O will first drive the input and 200ns later the output, resulting in
> the transition '1'->'0' on RST_p which, in turns, generates a transition
> '0'->'1' on RST_n, to be used internally as an active low reset.
>
>> This entire circuit seems to depend on VCC reaching "its functional
>> voltage level" before VCCI.  Do you know that this is true for your
>> board?
>
> Actually you do not need to have VCC functional *before* VCCI. I paste
> here an excerpt from the app note:
>
> (pag.2)
>> Before the start of power-up, all the I/Os are tristated. The I/Os
>> remain tristated during the power-up until the last supply (being
>> either VCCIBx or VCC) is powered to its functional activation voltage
>> level. After the last supply reaches the functional voltage level,
>> the outputs of the active I/O bank exits the tristate mode and drive
>> the logic at the input of the output buffer. Similarly, the input
>> buffers of the active I/O bank passes the external logic into the
>> FPGA fabric once the last supply reaches its functional voltage
>> level. The behavior of user I/Os is independent of the VCC and VCCIBx
>> power-up sequence

I hope all this is clear to you, it is not clear to me.  But if it 
works, then great.  There's your solution.  Will you have to prove to 
someone that this will work in a real system by analyzing the vendor's 
documents?  That might be a bit tough.

BTW, what is the fabric logic doing while all this Vcc ramping is going 
on.  What does it do if the logic VCC ramps up before VCCI does?  I 
guess if the I/Os are not enabled it doesn't matter much what it does if 
it gets a reset pulse before the outputs are enabled.  Can you assure that?

-- 

Rick

Article: 156053
Subject: Re: generating clocks
From: Richard Damon <Richard@Damon-Family.org>
Date: Thu, 14 Nov 2013 00:03:19 -0500
Links: << >>  << T >>  << A >>
On 11/12/13, 5:28 AM, eyecatcherdear@gmail.com wrote:
> @Tim Wescott: Yes they have to be generated on core. Actually I need
> these clocks to implement 3/4 punctured coding with output data rate
> as 150MHz. 150 and 112.5 are not of very high precision when
> generated from one core.
> 
> @Richard Damon: Yeah I agree to that. But atleast closer. I am going
> to try your method but you said "internal frequencey of 450.016 MHz
> (14.063*32) and then divide that by 3 and 4 for the two high speed
> clocks, which puts them less than 36 ppm high." I don't understand
> the last part. Why is it required to put them less than 36ppm high?

My comment on less than 36 ppm high is that the actual number for this
is a bit less than 36 ppm, so it show the error that you WILL get, you
need to see if that is good enough.
> 
> Is there any document you can recommend for clock generation which
> discusses the PLL clock cores in detail? I get confused with multiple
> clock generation.
> 
> I was wondering if  I cascade two cores? The user guide says it
> allows to generate 6 clocks that means 2 cores. I tried that using
> one to generate 150MHz and then generate 112.5 and 14.063 from 150
> but  the last 2 clocks did not generate.
> 

The chip document should have the information needed.

Article: 156054
Subject: Re: reset strategy FPGA Igloo
From: alb <alessandro.basili@cern.ch>
Date: Thu, 14 Nov 2013 17:24:32 +0100
Links: << >>  << T >>  << A >>
Hi Rick,

On 14/11/2013 02:10, rickman wrote:
>> []
>>> The app note goes into great detail about the timing of VCC and VCCI.
>>> In this discussion I believe they are talking about the input from
>>> the IBUF (RST_p) when they say, "The I/Os are tristated and the core
>>> logic detects '1' on the inputs from the boundary scan register
>>> (BSR)."  It is not clear what sets the value in the BSR.  It is also
>>> not clear how this determines the value of the RST_p signal.
>>
>> Between the I/O Bank and the FPGA core there's the BSR mandated by the
>> IEEE-1149.1 standard (JTAG) that you can control during programming. I'm
>> trying to look for 'default' values, but that is not essential since
>> when both VCC and VCCI will be above the functional voltage level the
>> I/O will first drive the input and 200ns later the output, resulting in
>> the transition '1'->'0' on RST_p which, in turns, generates a transition
>> '0'->'1' on RST_n, to be used internally as an active low reset.
>>
>>> This entire circuit seems to depend on VCC reaching "its functional
>>> voltage level" before VCCI.  Do you know that this is true for your
>>> board?
>>
>> Actually you do not need to have VCC functional *before* VCCI. I paste
>> here an excerpt from the app note:
>>
>> (pag.2)
>>> Before the start of power-up, all the I/Os are tristated. The I/Os
>>> remain tristated during the power-up until the last supply (being
>>> either VCCIBx or VCC) is powered to its functional activation voltage
>>> level. After the last supply reaches the functional voltage level,
>>> the outputs of the active I/O bank exits the tristate mode and drive
>>> the logic at the input of the output buffer. Similarly, the input
>>> buffers of the active I/O bank passes the external logic into the
>>> FPGA fabric once the last supply reaches its functional voltage
>>> level. The behavior of user I/Os is independent of the VCC and VCCIBx
>>> power-up sequence
> 
> I hope all this is clear to you, it is not clear to me.  But if it
> works, then great.  There's your solution.

I do not get what is not clear for you, it might be I'm missing something.

> Will you have to prove to
> someone that this will work in a real system by analyzing the vendor's
> documents?  That might be a bit tough.

Not more than proving that any other piece of the logic works. My system
is relying on the internal PLL properly working and I only have the
datasheet to consult. What else should i be considering?

> BTW, what is the fabric logic doing while all this Vcc ramping is going
> on.  What does it do if the logic VCC ramps up before VCCI does?  I
> guess if the I/Os are not enabled it doesn't matter much what it does if
> it gets a reset pulse before the outputs are enabled.  Can you assure that?

The I/O are tristated until the *last* supply is powered. What the
internal logic does before that point is kind of useless to speculate on
since whichever state will end up with it will come back to a known one
after reset.

Article: 156055
Subject: Re: reset strategy FPGA Igloo
From: rickman <gnuarm@gmail.com>
Date: Fri, 15 Nov 2013 02:20:35 -0500
Links: << >>  << T >>  << A >>
On 11/14/2013 11:24 AM, alb wrote:
> Hi Rick,
>
> On 14/11/2013 02:10, rickman wrote:
>>> []
>>>> The app note goes into great detail about the timing of VCC and VCCI.
>>>> In this discussion I believe they are talking about the input from
>>>> the IBUF (RST_p) when they say, "The I/Os are tristated and the core
>>>> logic detects '1' on the inputs from the boundary scan register
>>>> (BSR)."  It is not clear what sets the value in the BSR.  It is also
>>>> not clear how this determines the value of the RST_p signal.
>>>
>>> Between the I/O Bank and the FPGA core there's the BSR mandated by the
>>> IEEE-1149.1 standard (JTAG) that you can control during programming. I'm
>>> trying to look for 'default' values, but that is not essential since
>>> when both VCC and VCCI will be above the functional voltage level the
>>> I/O will first drive the input and 200ns later the output, resulting in
>>> the transition '1'->'0' on RST_p which, in turns, generates a transition
>>> '0'->'1' on RST_n, to be used internally as an active low reset.
>>>
>>>> This entire circuit seems to depend on VCC reaching "its functional
>>>> voltage level" before VCCI.  Do you know that this is true for your
>>>> board?
>>>
>>> Actually you do not need to have VCC functional *before* VCCI. I paste
>>> here an excerpt from the app note:
>>>
>>> (pag.2)
>>>> Before the start of power-up, all the I/Os are tristated. The I/Os
>>>> remain tristated during the power-up until the last supply (being
>>>> either VCCIBx or VCC) is powered to its functional activation voltage
>>>> level. After the last supply reaches the functional voltage level,
>>>> the outputs of the active I/O bank exits the tristate mode and drive
>>>> the logic at the input of the output buffer. Similarly, the input
>>>> buffers of the active I/O bank passes the external logic into the
>>>> FPGA fabric once the last supply reaches its functional voltage
>>>> level. The behavior of user I/Os is independent of the VCC and VCCIBx
>>>> power-up sequence
>>
>> I hope all this is clear to you, it is not clear to me.  But if it
>> works, then great.  There's your solution.
>
> I do not get what is not clear for you, it might be I'm missing something.

There is language in the documents you have provided that is not clear. 
  They talk about the boundary scan logic but don't explain how this 
impacts the start up operation.


>> Will you have to prove to
>> someone that this will work in a real system by analyzing the vendor's
>> documents?  That might be a bit tough.
>
> Not more than proving that any other piece of the logic works. My system
> is relying on the internal PLL properly working and I only have the
> datasheet to consult. What else should i be considering?

But you *aren't* relying on the data sheet.  You are relying on an app 
note that seems to have gaps from what I have seen.  I just can't fully 
grasp how the chip is expected to operate.  They have boundary scan 
logic which has to be reset on power up.  Where does that reset come 
from?  Does the boundary scan logic impact this reset strategy at all? 
Can you show this from the documentation?


>> BTW, what is the fabric logic doing while all this Vcc ramping is going
>> on.  What does it do if the logic VCC ramps up before VCCI does?  I
>> guess if the I/Os are not enabled it doesn't matter much what it does if
>> it gets a reset pulse before the outputs are enabled.  Can you assure that?
>
> The I/O are tristated until the *last* supply is powered. What the
> internal logic does before that point is kind of useless to speculate on
> since whichever state will end up with it will come back to a known one
> after reset.

The IOs are tristated, but what is going on with the inputs?  This is 
all being explained piecemeal so I can't see the full picture to know 
that all of the timing works.  Also realize that I read your post and 
try to remember what you have written.  Then I don't think about this 
for days until the next post.  So I don't remember all the details.  If 
you have explained something a week ago I have long since forgotten it.

If you are happy, then it doesn't matter if I understand it.  But from 
what you have said, there will be some sort of review of your approach. 
  You need to be able to justify all this adequately for the review.

-- 

Rick

Article: 156056
Subject: Cyclone V hard memory controller
From: baum <rf.baumgartner@arcor.de>
Date: Fri, 15 Nov 2013 13:30:59 +0100
Links: << >>  << T >>  << A >>
Hi,

I try to implement a DDR3 hard memory controller in a Cyclone v device
a 5CGXFC3B6F23C7.

I created an DDR3 hard memory controller IP core with the Megawizard, 
integrated the core in my design and added my design files in Quartus.

The fitter of Quartus gives following error message

Error (15332): Port SHIFTEN of cyclonev_pll_reconfig
"HeadTop:I_HeadTop|DDR3Controller:I_MemCtrlBlk|Ddr3MemCtrl:Ddr3MemCtrl_1|Ddr3MemCtrl_000 

2:ddr3memctrl_inst|Ddr3MemCtrl_pll0:pll0|pll1~PLL_RECONFIG" has 11 
connections, but the maximum
bus width of port SHIFTEN is 9

In the file Ddr3MemCtrl_pll0 there are 11 generic_pll instances and as 
far as I know the Cyclone Pll has only 9 clock outputs so I assume the 
error message refers to this and barks about the two additional clock 
outputs.

In the Megawizard there is no switch to select the number of clock 
outputs of the hard memory controller.

I tried to synthesise the example created by the Megawizard, but the 
funny thing is this example is not for the Cyclone V device I specified 
in Quartus and the fitter ends with an error message too.
This time not about the Pll but about some errors with output pins.

So my question is:
Has anybody implemented successfully a design with a DDR3 hard memory 
controller in a Cyclone v device or stumbled on the same error message 
as above.

Btw. I use Quartus 13.1 according to Altera the latest version but IMHO 
not the greatest.

Robert


Article: 156057
Subject: Re: Cyclone V hard memory controller
From: =?ISO-8859-1?Q?Adam_G=F3rski?= <gorskiamalpa@wpkropkapl>
Date: Sat, 16 Nov 2013 13:49:38 +0100
Links: << >>  << T >>  << A >>
W dniu 2013-11-15 13:30, baum pisze:
> Hi,
>
> I try to implement a DDR3 hard memory controller in a Cyclone v device
> a 5CGXFC3B6F23C7.
>
> I created an DDR3 hard memory controller IP core with the Megawizard,
> integrated the core in my design and added my design files in Quartus.
>
> The fitter of Quartus gives following error message
>
> Error (15332): Port SHIFTEN of cyclonev_pll_reconfig
> "HeadTop:I_HeadTop|DDR3Controller:I_MemCtrlBlk|Ddr3MemCtrl:Ddr3MemCtrl_1|Ddr3MemCtrl_000
>
> 2:ddr3memctrl_inst|Ddr3MemCtrl_pll0:pll0|pll1~PLL_RECONFIG" has 11
> connections, but the maximum
> bus width of port SHIFTEN is 9
>
> In the file Ddr3MemCtrl_pll0 there are 11 generic_pll instances and as
> far as I know the Cyclone Pll has only 9 clock outputs so I assume the
> error message refers to this and barks about the two additional clock
> outputs.
>
> In the Megawizard there is no switch to select the number of clock
> outputs of the hard memory controller.
>
> I tried to synthesise the example created by the Megawizard, but the
> funny thing is this example is not for the Cyclone V device I specified
> in Quartus and the fitter ends with an error message too.
> This time not about the Pll but about some errors with output pins.
>
> So my question is:
> Has anybody implemented successfully a design with a DDR3 hard memory
> controller in a Cyclone v device or stumbled on the same error message
> as above.
>
> Btw. I use Quartus 13.1 according to Altera the latest version but IMHO
> not the greatest.
>
> Robert
>

Hi Robert,

Your descriptiion is too narrow to say something.
If you need my help , send to me whole example project, then I will say 
something more.

Adam

Article: 156058
Subject: Re: Cyclone V hard memory controller
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 16 Nov 2013 18:35:30 +0000 (GMT)
Links: << >>  << T >>  << A >>
baum <rf.baumgartner@arcor.de> wrote:
> Hi,
> 
> I try to implement a DDR3 hard memory controller in a Cyclone v device
> a 5CGXFC3B6F23C7.
> 
> I created an DDR3 hard memory controller IP core with the Megawizard, 
> integrated the core in my design and added my design files in Quartus.
> 
> The fitter of Quartus gives following error message

I have no experience with the CycV, but are you sure the pin attributes are
set correctly?  There's usually a TCL file output by Qsys that you have to
run in Quartus to set the pin parameters before synthesis.  You only have to
run it once (the settings then go into your .qsf file).  If you don't do
this synthesis may fail because it incorrectly assigns pins and then fails
when those pins don't have the right properties.

Theo

Article: 156059
Subject: Re: generating clocks
From: eyecatcherdear@gmail.com
Date: Sun, 17 Nov 2013 23:02:52 -0800 (PST)
Links: << >>  << T >>  << A >>
Thanks for all that info. I totally understand the PLL phenomenon but the core has a limitation of generating clocks from 0 to 350MHz. I am using Actel Libero IDE evaluation version 9.1. The input clock rate of PROASIC3 is 40MHz. 

I can't find any such document where more than one core is used to generate clocks or anyway to produce such clocks in actel.
(The actel PLL core lets you enter your required frequency and then generates the clock with the highest precision unlike xilinx ISE where you have to place dividers and multipliers).

I'll keep looking and trying different approaches with PLL.
Thanks anyway for all your help.


Article: 156060
Subject: Re: reset strategy FPGA Igloo
From: alb <alessandro.basili@cern.ch>
Date: Mon, 18 Nov 2013 17:13:34 +0100
Links: << >>  << T >>  << A >>
Hi Rick,

On 15/11/2013 08:20, rickman wrote:
[]
>>>> (pag.2)
>>>>> Before the start of power-up, all the I/Os are tristated. The I/Os
>>>>> remain tristated during the power-up until the last supply (being
>>>>> either VCCIBx or VCC) is powered to its functional activation voltage
>>>>> level. After the last supply reaches the functional voltage level,
>>>>> the outputs of the active I/O bank exits the tristate mode and drive
>>>>> the logic at the input of the output buffer. Similarly, the input
>>>>> buffers of the active I/O bank passes the external logic into the
>>>>> FPGA fabric once the last supply reaches its functional voltage
>>>>> level. The behavior of user I/Os is independent of the VCC and VCCIBx
>>>>> power-up sequence
>>>
>>> I hope all this is clear to you, it is not clear to me.  But if it
>>> works, then great.  There's your solution.
>>
>> I do not get what is not clear for you, it might be I'm missing
>> something.
> 
> There is language in the documents you have provided that is not clear.
>  They talk about the boundary scan logic but don't explain how this
> impacts the start up operation.

Well, it is possible that i misunderstood that part, but reading the
app. note again it looks to me that when the I/O is *not* enabled (i.e.
prior to both VCC and VCCIBx operational) the fabric logic is driven by
the BSR register.

Since prior to both VCC and VCCIBx operational the I/O is tristated, I
do not care much about what is going on internally since it is not going
to affect the I/O.

OTOH when both VCC and VCCIBx are operational there's a sequence of
'activation' of the input first and the output secondly which provides
the '0'->'1' condition for an active low reset labelled in the document
as RST_n.

>>> Will you have to prove to
>>> someone that this will work in a real system by analyzing the vendor's
>>> documents?  That might be a bit tough.
>>
>> Not more than proving that any other piece of the logic works. My system
>> is relying on the internal PLL properly working and I only have the
>> datasheet to consult. What else should i be considering?
> 
> But you *aren't* relying on the data sheet.  You are relying on an app
> note that seems to have gaps from what I have seen.  I just can't fully
> grasp how the chip is expected to operate.  They have boundary scan
> logic which has to be reset on power up.  Where does that reset come
> from?  Does the boundary scan logic impact this reset strategy at all?

The BSR is normally 'reset' through the JTAG port (either synchronously
or asynchronously), but does not really matter because when the JTAG is
not active the chip drives output from its internal fabric and samples
input transparently.

> Can you show this from the documentation?

Nope, I'm trying to look for the JTAG implementation description of this
device, but I'm having hard time to find it.

[]
>> The I/O are tristated until the *last* supply is powered. What the
>> internal logic does before that point is kind of useless to speculate on
>> since whichever state will end up with it will come back to a known one
>> after reset.
> 
> The IOs are tristated, but what is going on with the inputs?  This is
> all being explained piecemeal so I can't see the full picture to know
> that all of the timing works.  Also realize that I read your post and
> try to remember what you have written.  Then I don't think about this
> for days until the next post.  So I don't remember all the details.  If
> you have explained something a week ago I have long since forgotten it.

I completely understand.

> 
> If you are happy, then it doesn't matter if I understand it.  But from
> what you have said, there will be some sort of review of your approach.
>  You need to be able to justify all this adequately for the review.

Yep!


Article: 156061
Subject: Re: reset strategy FPGA Igloo
From: rickman <gnuarm@gmail.com>
Date: Mon, 18 Nov 2013 21:20:19 -0500
Links: << >>  << T >>  << A >>
On 11/18/2013 11:13 AM, alb wrote:
> Hi Rick,
>
> On 15/11/2013 08:20, rickman wrote:
>> The IOs are tristated, but what is going on with the inputs?  This is
>> all being explained piecemeal so I can't see the full picture to know
>> that all of the timing works.  Also realize that I read your post and
>> try to remember what you have written.  Then I don't think about this
>> for days until the next post.  So I don't remember all the details.  If
>> you have explained something a week ago I have long since forgotten it.
>
> I completely understand.

I think in terms of pictures, so I probably wouldn't fully understand 
all of this until I saw a timing diagram.  Nothing fancy, just something 
that shows all the events in a timeline along with the various signals 
in the reset chain.  I suspect something like this would be good 
material for your review.  I believe the events are like this...

Vcc     _____------------
VccIO   ________---------

--or--

Vcc     ________---------
VccIO   _____------------

-- results --

BSR drives internal logic, High = drives, Lo = not driving
         ---------________

Inputs enabled
         _________--------
Outputs enabled
         ____________-----
Input to reset logic
         xxxxxxxxx---_____

The reset is your reset circuit for the rest of the chip.

Now that I see it in diagram form, I think you have it covered.

-- 

Rick

Article: 156062
Subject: Re: legacy Xilinx software
From: Jon Elson <jmelson@wustl.edu>
Date: Thu, 21 Nov 2013 11:00:02 -0600
Links: << >>  << T >>  << A >>
Jon Elson wrote:

Well, a little bit of an update.  I couldn't get xilprog
to work, and can't contact the author.  I then did get
xc3sprog to run and correctly ID a CPLD.  So, I'm guessing it
could program one, too, but I haven't tried that.  But,
accessing the parallel port and talking to the JTAG device
through a DLC5 (parallel cable III) was way farther than
I had gotten with anything else.

I think Impact will work if I have the kernel source installed
before I try to compile the cable drivers.  Also, one big trick I
found online is to rename the whole digilent/adept directory.
Something in there causes Impact to just terminate when it gets to
the cable setup.  Since I don't have a Digilent device, that
shouldn't affect me.

Jon

Article: 156063
Subject: FPGA Cryptosystem
From: youngejoe <cyounge28@gmail.com>
Date: Thu, 21 Nov 2013 15:04:10 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello all

Proposed idea from my research to date:
Two FPGA encryption modules: Both will have an identical encryption algorit=
hm; key management something I need to research further.
Bob has plain text message. He, perhaps through a GUI, sends the file to hi=
s FPGA 'cryptosystem' via USB which subsequently encrypts the data. Returns=
 PC as cipher text, he sends data through unsecured network(leased lines, m=
icrowave etc).=20
Alice receives message, sends her module which then decrypts the message.

I have returned to college to up skill and as such have been given my final=
 year project. I'm not looking for code, or to be spoon fed, merely looking=
 to draw on peoples experience and opinion! I have completed embedded syste=
ms projects involving microcontrollers, microprocessors in the past but FPG=
As are brand spanking new to me. I have agreed with my lecturer, who is hap=
py to leave me 'at it' to stick to: FPGAs, cryptography & communications.
Again, I will not progress into looking for code etc etc, just honest opini=
ons and suggestions, thank you for your time, jyoung Irl.

P.s I'm not in the NSA :)

Article: 156064
Subject: Re: FPGA Cryptosystem
From: rickman <gnuarm@gmail.com>
Date: Thu, 21 Nov 2013 18:18:36 -0500
Links: << >>  << T >>  << A >>
On 11/21/2013 6:04 PM, youngejoe wrote:
> Hello all
>
> Proposed idea from my research to date:
> Two FPGA encryption modules: Both will have an identical encryption algorithm; key management something I need to research further.
> Bob has plain text message. He, perhaps through a GUI, sends the file to his FPGA 'cryptosystem' via USB which subsequently encrypts the data. Returns PC as cipher text, he sends data through unsecured network(leased lines, microwave etc).
> Alice receives message, sends her module which then decrypts the message.
>
> I have returned to college to up skill and as such have been given my final year project. I'm not looking for code, or to be spoon fed, merely looking to draw on peoples experience and opinion! I have completed embedded systems projects involving microcontrollers, microprocessors in the past but FPGAs are brand spanking new to me. I have agreed with my lecturer, who is happy to leave me 'at it' to stick to: FPGAs, cryptography&  communications.
> Again, I will not progress into looking for code etc etc, just honest opinions and suggestions, thank you for your time, jyoung Irl.
>
> P.s I'm not in the NSA :)

Interesting idea.  That's my opinion.

Was there something more specific you had in mind?  Maybe an actual 
question?

Oh, before you go too far with your idea, you might want to look up 
someone named Ralph Zimmermann and his idea, PGP.  Just so you know all 
the issues involved.

-- 

Rick

Article: 156065
Subject: Re: FPGA Cryptosystem
From: hamilton <hamilton@nothere.com>
Date: Thu, 21 Nov 2013 17:00:37 -0700
Links: << >>  << T >>  << A >>
On 11/21/2013 4:18 PM, rickman wrote:
> On 11/21/2013 6:04 PM, youngejoe wrote:
>> Hello all
>>
>> Proposed idea from my research to date:
>> Two FPGA encryption modules: Both will have an identical encryption
>> algorithm; key management something I need to research further.
>> Bob has plain text message. He, perhaps through a GUI, sends the file
>> to his FPGA 'cryptosystem' via USB which subsequently encrypts the
>> data. Returns PC as cipher text, he sends data through unsecured
>> network(leased lines, microwave etc).
>> Alice receives message, sends her module which then decrypts the message.
>>
>> I have returned to college to up skill and as such have been given my
>> final year project. I'm not looking for code, or to be spoon fed,
>> merely looking to draw on peoples experience and opinion! I have
>> completed embedded systems projects involving microcontrollers,
>> microprocessors in the past but FPGAs are brand spanking new to me. I
>> have agreed with my lecturer, who is happy to leave me 'at it' to
>> stick to: FPGAs, cryptography&  communications.
>> Again, I will not progress into looking for code etc etc, just honest
>> opinions and suggestions, thank you for your time, jyoung Irl.
>>
>> P.s I'm not in the NSA :)
>
> Interesting idea.  That's my opinion.
>
> Was there something more specific you had in mind?  Maybe an actual
> question?
>
> Oh, before you go too far with your idea, you might want to look up
> someone named Ralph Zimmermann and his idea, PGP.

http://en.wikipedia.org/wiki/Phil_Zimmermann

  Just so you know all
> the issues involved.
>


Article: 156066
Subject: Re: Granularity of components for FPGA synthesis?
From: Kip Ingram <kip@liberty.kipingram.com>
Date: Thu, 21 Nov 2013 18:13:22 -0600
Links: << >>  << T >>  << A >>
* chthon <jurgen.defurne@gmail.com> wrote:
> Thanks for the answers. I will keep what I have now of floorplanning, 
> because I like to have a clean result (ISE seems to throw stuff around 
> like an expanding gas cloud), but I will keep it at that. I now get 
> 190 MHz, I do not have a spec, but I wanted to know how fast I 
> (clockwise) I could make my design. And it is now mostly hampered 
> through the fact that I use 64k bytes of block RAM, which I really had 
> to constrain, because without this it uses block RAM in weird places.
>
> Regards,
>
> Jurgen

Hi Jurgen.  Sorry to join the party late.  I tend to buck the
conventional wisdom on things like this.  I did my first programmable
logic design back in the 1980's when we used PALs (22V10, etc.)
Generally you took *total* control of your design.  You could use
equations, but even when I did I liked knowing exactly what was going on
with each and every fuse.

I miss those days - the modern trend seems to be for us to "program
hardware"; it all is starting to feel like software design.  I still
like to floor plan tight little units of logic.  Everyone here may be
right, but my answer to the "if the tools will get you there, why
bother?" is...

"Because I can."

-- Kip

Article: 156067
Subject: Re: Legal Issues Reproducing Old CPU
From: Kip Ingram <kip@liberty.kipingram.com>
Date: Thu, 21 Nov 2013 18:17:12 -0600
Links: << >>  << T >>  << A >>
* GaborSzakacs <gabor@alacron.com> wrote:
> Philipp Klaus Krause wrote:
>> Am 18.09.2013 06:30, schrieb ditiris@gmail.com:
>>> This might not be the best group to ask, but I figured I would start
>>> here. I need to duplicate a 35-year-old CPU. Are there legal
>>> ramifications doing this?
>>>
>>> For instance on OpenCores they have a partially-compliant C54x DSP
>>> core. I assume the partial compliance is in part not to run into
>>> licensing issues and have TI sue them. However, I need to duplicate
>>> the CPU's instruction set and associated cycle count exactly, so I'm
>>> pretty much going to copy the CPU using the existing documentation.
>>>
>>> Thanks in advance for the help.
>>>
>> 
>> IANAL, but AFAIK, reproducing instruction set and cycle count exactly is
>> OK, unless some of the instructions are patented. Patents expire after
>> at most 20 years in any part of the world that I know of, so with a
>> 35-year-old CPU you should be ok.
>> 
>> Philipp
>
> I think you need to be careful.  While patents do expire (patents from
> 35 years ago expired after 17 years IIRC), copyrights generally do not.
> On the other hand it would be unusual for the owners of such old
> copyrights to pursue legal action against you unless you were making
> a lot of these devices.  Still you're better off getting legal advice
> from someone who knows more about these issues, especially if you're
> intending to make significant money from this copying effort.
>
> -- 
> Gabor

I don't think you can copyright an instruction set, can you?  I thought
that some of the "classic" reverse engineering precedents had addressed
that.  Similar to the old "clean room BIOS reverse engineering"
exercises.

I am not a lawyer, and no one should take this as proper legal advice,
but I believe if you design the processor logic in an "untainted" way
(i.e., you don't literally steal circuitry or microcode) then you are
free to design a gadget that uses any instruction set you wish.

-- Kip

Article: 156068
Subject: Re: Legal Issues Reproducing Old CPU
From: rickman <gnuarm@gmail.com>
Date: Thu, 21 Nov 2013 20:58:10 -0500
Links: << >>  << T >>  << A >>
On 11/21/2013 7:17 PM, Kip Ingram wrote:
> * GaborSzakacs<gabor@alacron.com>  wrote:
>> Philipp Klaus Krause wrote:
>>> Am 18.09.2013 06:30, schrieb ditiris@gmail.com:
>>>> This might not be the best group to ask, but I figured I would start
>>>> here. I need to duplicate a 35-year-old CPU. Are there legal
>>>> ramifications doing this?
>>>>
>>>> For instance on OpenCores they have a partially-compliant C54x DSP
>>>> core. I assume the partial compliance is in part not to run into
>>>> licensing issues and have TI sue them. However, I need to duplicate
>>>> the CPU's instruction set and associated cycle count exactly, so I'm
>>>> pretty much going to copy the CPU using the existing documentation.
>>>>
>>>> Thanks in advance for the help.
>>>>
>>>
>>> IANAL, but AFAIK, reproducing instruction set and cycle count exactly is
>>> OK, unless some of the instructions are patented. Patents expire after
>>> at most 20 years in any part of the world that I know of, so with a
>>> 35-year-old CPU you should be ok.
>>>
>>> Philipp
>>
>> I think you need to be careful.  While patents do expire (patents from
>> 35 years ago expired after 17 years IIRC), copyrights generally do not.
>> On the other hand it would be unusual for the owners of such old
>> copyrights to pursue legal action against you unless you were making
>> a lot of these devices.  Still you're better off getting legal advice
>> from someone who knows more about these issues, especially if you're
>> intending to make significant money from this copying effort.
>>
>> --
>> Gabor
>
> I don't think you can copyright an instruction set, can you?  I thought
> that some of the "classic" reverse engineering precedents had addressed
> that.  Similar to the old "clean room BIOS reverse engineering"
> exercises.

Copyright applies to the expression of an artistic work.  So no, an 
instruction set can not be copyrighted.  However, the nemonics for 
opcodes can.  That is why Zilog had to use a different assembler for the 
Z80 even though it was binary upward compatible with the 8080.

-- 

Rick

Article: 156069
Subject: Re: Legal Issues Reproducing Old CPU
From: Kip Ingram <kip@liberty.kipingram.com>
Date: Thu, 21 Nov 2013 21:09:45 -0600
Links: << >>  << T >>  << A >>
* rickman <gnuarm@gmail.com> wrote:
> On 11/21/2013 7:17 PM, Kip Ingram wrote:
>> * GaborSzakacs<gabor@alacron.com>  wrote:
>>> Philipp Klaus Krause wrote:
>>>> Am 18.09.2013 06:30, schrieb ditiris@gmail.com:
>>>>> This might not be the best group to ask, but I figured I would start
>>>>> here. I need to duplicate a 35-year-old CPU. Are there legal
>>>>> ramifications doing this?
>>>>>
>>>>> For instance on OpenCores they have a partially-compliant C54x DSP
>>>>> core. I assume the partial compliance is in part not to run into
>>>>> licensing issues and have TI sue them. However, I need to duplicate
>>>>> the CPU's instruction set and associated cycle count exactly, so I'm
>>>>> pretty much going to copy the CPU using the existing documentation.
>>>>>
>>>>> Thanks in advance for the help.
>>>>>
>>>>
>>>> IANAL, but AFAIK, reproducing instruction set and cycle count exactly is
>>>> OK, unless some of the instructions are patented. Patents expire after
>>>> at most 20 years in any part of the world that I know of, so with a
>>>> 35-year-old CPU you should be ok.
>>>>
>>>> Philipp
>>>
>>> I think you need to be careful.  While patents do expire (patents from
>>> 35 years ago expired after 17 years IIRC), copyrights generally do not.
>>> On the other hand it would be unusual for the owners of such old
>>> copyrights to pursue legal action against you unless you were making
>>> a lot of these devices.  Still you're better off getting legal advice
>>> from someone who knows more about these issues, especially if you're
>>> intending to make significant money from this copying effort.
>>>
>>> --
>>> Gabor
>>
>> I don't think you can copyright an instruction set, can you?  I thought
>> that some of the "classic" reverse engineering precedents had addressed
>> that.  Similar to the old "clean room BIOS reverse engineering"
>> exercises.
>
> Copyright applies to the expression of an artistic work.  So no, an 
> instruction set can not be copyrighted.  However, the nemonics for 
> opcodes can.  That is why Zilog had to use a different assembler for the 
> Z80 even though it was binary upward compatible with the 8080.
>
> -- 
>
> Rick

Yeah, that makes sense...  So you can functionally duplicate a
processor, but not "artistically."  Good distinction...

-- Kip

Article: 156070
Subject: Re: FPGA Cryptosystem
From: Aleksandar Kuktin <akuktin@gmail.com>
Date: Fri, 22 Nov 2013 04:22:07 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Thu, 21 Nov 2013 18:18:36 -0500, rickman wrote:

> On 11/21/2013 6:04 PM, youngejoe wrote:
>> Hello all
>>
>> Proposed idea from my research to date:
>> Two FPGA encryption modules: Both will have an identical encryption
>> algorithm; key management something I need to research further.
>> Bob has plain text message. He, perhaps through a GUI, sends the file
>> to his FPGA 'cryptosystem' via USB which subsequently encrypts the
>> data. Returns PC as cipher text, he sends data through unsecured
>> network(leased lines, microwave etc).
>> Alice receives message, sends her module which then decrypts the
>> message.
>> 
>> [snip]
>> 
>> Again, I will not progress into looking for code etc etc, just honest
>> opinions and suggestions, thank you for your time, jyoung Irl.
>>
>> P.s I'm not in the NSA :)
> 
> Interesting idea.  That's my opinion.

The only proper way to do cryptography, in mine. Keeping the keys on the 
same machine as the rest of your software is just asking for trouble.

I have a plan to eventually produce a device with a similar concept as 
the above, just in a RFID package and implantable. So that stealing your 
crypto keys becomes a tad bit more complicated. :)

Also, I am not sure about full-blown encryption on the crypto-device, but 
signing, verifying, and small time encryption (like asimetrically 
encrypting/decrypting simetrical keys and similar) are certainly viable.

Article: 156071
Subject: Mill: FPGA version?
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Fri, 22 Nov 2013 15:20:09 +0000 (UTC)
Links: << >>  << T >>  << A >>
I've been wondering if there could be a successful (not too large,
reasonable clock frequency) soft-core FPGA version of a low end variant of
the Mill.  One issue with FPGAs is that only two-port memory is available. 
It's not so hard to make extra read ports with these, but extra write ports
are a big problem.  This pretty much precludes any sane implementation of
Tomasulo's algorithm for OOE.

If I understand "the belt" properly, the number of write ports is set to
just the number of pipelines (or maybe to two to support the spilling).  The
pipes need to be able to read from anywhere, but we can do that with extra
read ports and one extra mux stage.  Anyway, it seems like a nice way to get
superscalar on an FPGA.

Perhaps Out of the Box Computing has an FPGA version now already for bring
up? Very curious what clock frequency they are getting..

-- 
/*  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: 156072
Subject: Re: Mill: FPGA version?
From: Ivan Godard <ivan@ootbcomp.com>
Date: Fri, 22 Nov 2013 08:19:51 -0800
Links: << >>  << T >>  << A >>
On 11/22/2013 7:20 AM, Joseph H Allen wrote:
> I've been wondering if there could be a successful (not too large,
> reasonable clock frequency) soft-core FPGA version of a low end variant of
> the Mill.  One issue with FPGAs is that only two-port memory is available.
> It's not so hard to make extra read ports with these, but extra write ports
> are a big problem.  This pretty much precludes any sane implementation of
> Tomasulo's algorithm for OOE.
>
> If I understand "the belt" properly, the number of write ports is set to
> just the number of pipelines (or maybe to two to support the spilling).  The
> pipes need to be able to read from anywhere, but we can do that with extra
> read ports and one extra mux stage.  Anyway, it seems like a nice way to get
> superscalar on an FPGA.
>
> Perhaps Out of the Box Computing has an FPGA version now already for bring
> up? Very curious what clock frequency they are getting..
>

We're working on an FPGA, but it's behind patents, fund raising, and 
talks, so it won't be soon :-(

As for your technical question, I am a software guy and don't know the 
innards of FPGAs so I have bounced your question to our hardware team 
and will post their answer.

Ivan

Article: 156073
Subject: Re: FPGA Cryptosystem
From: youngejoe <cyounge28@gmail.com>
Date: Fri, 22 Nov 2013 08:42:15 -0800 (PST)
Links: << >>  << T >>  << A >>
> Interesting idea.  That's my opinion.
>=20
>=20
>=20
> Was there something more specific you had in mind?  Maybe an actual=20
>=20
> question?
>=20
>=20
>=20
> Oh, before you go too far with your idea, you might want to look up=20
>=20
> someone named Ralph Zimmermann and his idea, PGP.  Just so you know all=
=20
>=20
> the issues involved.
>=20
>=20
>=20
> --=20
>=20
>=20
>=20
> Rick

Thanks for your reply. The issue I'm having is FPGA knowledge tbh. In resea=
rch mode, still trying to develop a good, real concept.

For example, an microcontroller project. I design and build my circuit on b=
readboards. Write (eg) embedded c and compile this into machine code using =
Keil uVision. I then insert my MCU in an in system programmer such as 'data=
man programmer' which will send the compiled machine code to the MCU which =
I can then insert my breadboard and see if the project works as planned!

With FPGAs, for the above mentioned project, would I would require two deve=
lopment boards connected to PC1 and PC2? My initial concept was to use 2 FP=
GAs resembling 2 flash drives.

PGP is very interesting - employing both asymmetric and symmetric encryptio=
n as well as digital signatures etc. I like the idea behind it. As its soft=
ware based, would it be difficult resembling it in hardware, say on FPGAs?

The main guideline I'm trying to stick is an FPGA based cryptosystem. Thank=
s

Article: 156074
Subject: microZed adventures
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Fri, 22 Nov 2013 08:57:12 -0800
Links: << >>  << T >>  << A >>


We're into this signal processing project, using a microZed/ZYNQ thing as the
compute engine.

After a week or so of work by an FPGA guy and a programmer, we can now actually
read and write an FPGA register from a C program, and wiggle a bit on a
connector pin. Amazingly, the uZed eval kit does not include a demo of this, and
the default boot image does not configure the FPGA!

We're using their build tools to embed the FPGA config into the boot image. We'd
really like to be able to have a C program read a bitstream file and reconfigure
the FPGA, but we haven't been able to figure that out.

If we run a C program that wiggles a pin as fast as it can, we can do a write to
the FPGA register about every 170 ns. Without any attempts at optimization (like
dedicating the second ARM core to the loop) we see stutters (OS stealing our
CPU) that last tens or hundreds of microseconds, occasionally a full
millisecond. That might get worse if we run TCP/IP sessions or host web pages or
something, so dedicating the second ARM to realtime stuff would be good.


-- 

John Larkin                  Highland Technology Inc
www.highlandtechnology.com   jlarkin at highlandtechnology dot com   

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME  analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators



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
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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