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 155925

Article: 155925
Subject: Re: reset strategy FPGA Igloo
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Wed, 16 Oct 2013 15:30:43 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <bc6vftF32k1U1@mid.individual.net>,
alb  <alessandro.basili@cern.ch> wrote:
>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.

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

Well one hack is to make a probabilistically correct reset pulse generator. 
Use a counter to generate a reset pulse and use random values for the start
and end of the pulse.  The counter will come up in some random state, but
most of the time you will still get a good reset pulse.  With enough bits
you should be able to get the chance of failure to be very small..  I
suspect an asynchronous counter will be better for this since (if you can
make on ein Igloo) it will be less likely that a clock glitch will upset the
entire count value.

I might do it if the FPGA is running an experiment.  I would not do it if
the FPGA is for a flight critical system: but then you should have TMR
anyway.

-- 
/*  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: 155926
Subject: Partnership Request
From: Dan Wawa <danwawa6@gmail.com>
Date: Wed, 16 Oct 2013 10:17:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi, I have designed a microprocessor that works as a USB device that I call=
 DorQ. Its function is to speed up the processing speed of any computer tha=
t it is connected to by a factor of several thousands of times. I call it t=
he concept of Parallel Bus Processing. My design is still in VHDL source co=
de and I need a partner to help fabricate/manufacture and market this new k=
ind of USB device. I repeat, this is a completely new USB device that will =
work with any PC in the world. Would you be interested in partnering with m=
e in this venture? Please contact me with your yes or no response or any id=
eas about companies that may accept designs from partners as part of their =
product lines. You may contact me at loumbut5@hotmail.com

Article: 155927
Subject: Re: reset strategy FPGA Igloo
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Wed, 16 Oct 2013 17:46:29 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <l3mbf3$mc1$1@pcls7.std.com>,
Joseph H Allen <jhallen@TheWorld.com> wrote:
>In article <bc6vftF32k1U1@mid.individual.net>,
>alb  <alessandro.basili@cern.ch> wrote:
>>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.

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

>Well one hack is to make a probabilistically correct reset pulse generator. 
>Use a counter to generate a reset pulse and use random values for the start
>and end of the pulse.  The counter will come up in some random state, but
>most of the time you will still get a good reset pulse.  With enough bits
>you should be able to get the chance of failure to be very small..  I
>suspect an asynchronous counter will be better for this since (if you can
>make on ein Igloo) it will be less likely that a clock glitch will upset the
>entire count value.

>I might do it if the FPGA is running an experiment.  I would not do it if
>the FPGA is for a flight critical system: but then you should have TMR
>anyway.

Here is the idea in code:

reg [7:0] cntr_1; // Powers up to some random value..
reg [7:0] cntr_2; // Chance is not high that they all power up to
reg [7:0] cntr_3; // their final value.
reg [7:0] cntr_4;

reg reset_l_1;
reg reset_l_2;
reg reset_l; // Main reset net

always @(posedge clk)
  begin
    if (lock && cntr_1 != 8'h55) cntr_1 <= cntr_1 + 1'd1;
    if (lock && cntr_2 != 8'hAA) cntr_2 <= cntr_2 + 1'd1;
    if (lock && cntr_3 != 8'hbb) cntr_3 <= cntr_3 + 1'd1;
    if (lock && cntr_4 != 8'h33) cntr_4 <= cntr_4 + 1'd1;
    reset_l_2 <= (cntr_1 == 8'h55) && (cntr_2 == 8'haa) && (cntr_3 == 8'hbb)
&& (cntr_4 == 8'h33);
    reset_l_1 <= reset_l_2;
    reset_l <= reset_l_1;
  end

Should be 1 / 2^32 chance of not having a good reset...
-- 
/*  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: 155928
Subject: Re: reset strategy FPGA Igloo
From: rickman <gnuarm@gmail.com>
Date: Wed, 16 Oct 2013 14:22:47 -0400
Links: << >>  << T >>  << A >>
On 10/11/2013 3:43 PM, Joseph H Allen wrote:
> In article<l39dsb$4q1$1@speranza.aioe.org>,
> glen herrmannsfeldt<gah@ugcs.caltech.edu>  wrote:
>
>> First, I agree with what Mark says.
>
>> 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.
>
>> You do still have to get the timing right, so you release it at
>> the right time relative to the clock edge.
>
> The timing provided by the global reset line is not good.. it's nowhere near
> as good as a global clock line as far as I understand.
>
> One way to deal with this is to have all of your state machines start in a
> reset state which does nothing but wait for a synchronous "start" edge which
> is generated after reset with a counter or a shift register.
>
> This has a big advantage that you no longer have to worry about global reset
> timing.  On the other hand, if you use libraries you may have no choice
> since you can't change the logic.

This really doesn't solve the problem.  The problem is that globally 
resetting all the state machines in a design can tax the routing and 
timing of the global reset signal.  If you do this the routing problem 
can be fixed by resynchronizing the reset to the clock before using it 
in a given section of logic that should be geographically local on the 
chip.  Otherwise you can give P&R some very tough problems to solve.

-- 

Rick

Article: 155929
Subject: Re: reset strategy FPGA Igloo
From: rickman <gnuarm@gmail.com>
Date: Wed, 16 Oct 2013 14:26:03 -0400
Links: << >>  << T >>  << A >>
On 10/16/2013 11:21 AM, alb wrote:
> 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.

I'm not familiar with automotive use.  I would think they would have 
been a much bigger company if there had been much automotive use of 
their parts.  Just one design win is 500,000 a year in that market.

I sort of lump space, avionic and defense into the same category since 
they have similar requirements and are all much smaller than commercial 
markets.  Perhaps we can call this generically "high rel" and also 
include the small commercial market segment.  High markup, low volume...


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

That is the crux of the problem.  While some brands of FPGAs do a 
reasonable job of detecting power on and resetting the entire device, it 
sounds like the Actel doesn't bother since... well, since it doesn't 
need to as long as it can rely on the user to reset it.


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

I'm not clear on this.  It sounds like you are using the timer in 
*place* of the lock signal from the PLL.  My point was to condition the 
lock signal from the PLL.  But since you say below that you don't know 
the state of the PLL lock signal at power up I suppose this won't work. 
  It would be a simple matter to test it though.  Or you can contact the 
factory.  Since there is no configuration process the logic of the PLL 
should be ready and working on power up I would expect.


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

The fact that you are checking the upper bits prevents any pruning of 
the counter.  I think your approach is to help assure that the counter 
has been reset before it will count down.  I would not think this was 
workable.  Either the counter is reset properly or the circuit can 
malfunction by lockup, possibly with global_rst = '0'.  Also be aware 
that you are really only using 5 check bits since the sixth is used to 
flag end of timeout.

If this is a high rel application, I would not want to rely on a five 
bit checksum to control a reset.  You say "guarantee" and "random", but 
I see the possibility that the counter starts up in the done state with 
reset never having been asserted, 1 in 64 chance.  If you check all the 
bits in the counter for the done state it is still a 1 in 4096 chance of 
malfunctioning without ever producing a reset out.

If you can't rely on the PLL lock signal to be asserted at power up, I 
don't think you can rely on *any* logic in the FPGA to compensate for 
this.  Why not investigate and find out if the PLL signal will work as a 
power on reset?  Contact the factory and/or test it yourself on the 
bench.  Bring the LOCK signal out to a pin and scope it while powering 
up the unit.

I think you need a reset signal for the device, period.  Even if you 
manage to supply a reset to all the FFs in your logic, is there nothing 
else on the chip that requires a reset like the PLL itself?  What other 
circuits are on the device other than the user configurable logic?  Does 
the data sheet talk about a requirement for the reset signal?

The PLL issue and the idea of using the I/O pin to generate a reset are 
both issues I would contact the factory about.  If I were in your shoes, 
I would push hard to have the module disqualified since the FPGA can not 
be assured to have been reset.  That is the part that is insanity!

-- 

Rick

Article: 155930
Subject: Re: Zynq devices, boards and suppliers
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Wed, 16 Oct 2013 19:51:48 +0100
Links: << >>  << T >>  << A >>
On 16/10/13 12:56, Frank Buss wrote:
> 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

Thanks.

I'd looked at that board a while ago, but at that time it
was insufficiently real. Having seen the standard of some
"open source" hardware[*] I'd like to see it be used in
anger before I committed to it. Contrariwise, longevity might
not be such an issue!

The low cost is remarkable. Before committing, I'd
want to find out:
   - how to disable or ignore the Epiphany processor,
     since it isn't useful to me
   - what proportion of the programmable logic resources
     would be available for me to use for my logic

[*] and some COTS hardware for that matter :(


Article: 155931
Subject: Re: Zynq devices, boards and suppliers
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Wed, 16 Oct 2013 21:38:24 +0100
Links: << >>  << T >>  << A >>
On 16/10/13 21:18, edward.ming.lee@gmail.com wrote:
>
>> 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.
>
> This is almost a desktop class chip.  Do you really need that power?  I wish they have something smaller.  I don't need dual core GHz core, but may be you do.

No I don't need that. But if it is there, I may find a use for it.

However, I do need one aspect of the SERDES I/O.


>>    - what proportion of the programmable logic resources
>>      would be available for me to use for my logic
>
> They says a Z7010 or Z7020.  But for $99, most likely Z7010, which has 28K logic cells available.
>
> If you are not building with chips, does it really matter with:
>
> 1. A $50 CPU + tiny FPGA (28K)
> or
> 2. A $30 CPU + $20 FPGA (500K)
>
> I am sure you can find a cheaper board with 2.

So am I. But cost isn't everything; my time is more important.
Hence my question about board suppliers, not FPGA devices.


Article: 155932
Subject: Re: reset strategy FPGA Igloo
From: gtwrek@sonic.net (Mark Curry)
Date: Wed, 16 Oct 2013 21:16:06 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <l3mli5$g8o$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>On 10/11/2013 3:43 PM, Joseph H Allen wrote:
>> In article<l39dsb$4q1$1@speranza.aioe.org>,
>> glen herrmannsfeldt<gah@ugcs.caltech.edu>  wrote:
>>
>>> First, I agree with what Mark says.
>>
>>> 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.
>>
>>> You do still have to get the timing right, so you release it at
>>> the right time relative to the clock edge.
>>
>> The timing provided by the global reset line is not good.. it's nowhere near
>> as good as a global clock line as far as I understand.
>>
>> One way to deal with this is to have all of your state machines start in a
>> reset state which does nothing but wait for a synchronous "start" edge which
>> is generated after reset with a counter or a shift register.
>>
>> This has a big advantage that you no longer have to worry about global reset
>> timing.  On the other hand, if you use libraries you may have no choice
>> since you can't change the logic.
>
>This really doesn't solve the problem.  The problem is that globally 
>resetting all the state machines in a design can tax the routing and 
>timing of the global reset signal.  If you do this the routing problem 
>can be fixed by resynchronizing the reset to the clock before using it 
>in a given section of logic that should be geographically local on the 
>chip.  Otherwise you can give P&R some very tough problems to solve.

Wow - can't keep up - lots of replies here.  The GSR from Xilinx isn't
the end all solution that Xilinx touts it as.  The release of the global
GSR is completely asynchronous.  It doesn't really matter much that 
router may have trouble routing this signal with low skew.  It's 
asynchronous - Murphy's law says that one FFs going to see the inactive 
edge of reset on one clock edge - the next FF's going to see the it on the 
following clock cycle.  Low skew likely lowers the likelihood of the event, 
but it can happen none-the-less and should be accounted for in your design.

I've gone into this in the Xilinx forums some, but you've got to be careful
on using that GSR...

Regards,

Mark

Article: 155933
Subject: Re: Zynq devices, boards and suppliers
From: MK <mk@nospam.co.uk>
Date: Thu, 17 Oct 2013 09:31:08 +0100
Links: << >>  << T >>  << A >>
On 16/10/2013 12:28, 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.
>
>    - 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.

You are taking a risk in basing a product on a development board - they 
aren't sold with that in mind and the suppliers don't see long term 
availability as part of the deal. There are quite  a lot of boards based 
on the Zynq around - eg: Mars ZX3- Zynq-7000 SO-DIMM module (which I 
have not used and don't recommend o not recommend.)
You should be able to find a board with long term support and actually 
intended for OEM supply.

Michael Kellett


Article: 155934
Subject: Re: Zynq devices, boards and suppliers
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Thu, 17 Oct 2013 10:07:47 +0100
Links: << >>  << T >>  << A >>
On 17/10/13 09:31, MK wrote:
> You are taking a risk in basing a product on a development board - they aren't sold with that in mind and the suppliers don't see long term availability as part of the deal. There are quite  a lot of
> boards based on the Zynq around - eg: Mars ZX3- Zynq-7000 SO-DIMM module (which I have not used and don't recommend o not recommend.)
> You should be able to find a board with long term support and actually intended for OEM supply.

Thanks. Your points are well noted. Fortunately it
isn't actually for a product, only a prototype.

My concern is that I want/need decent documentation
and/or community support - and that might not be
there with a board that only has a very short
production life.

Fundamentally I want to grab my data, process it
and display it. I don't want to become an expert
in creating a linux for board Munge v0.9 using
tool Frobnatz v123.456!

Hence my questions about /which/ suppliers/toolsets
that people have found to be "reliable" by
the above definition.


Article: 155935
Subject: Re: Zynq devices, boards and suppliers
From: Antti <antti.lukats@gmail.com>
Date: Thu, 17 Oct 2013 11:31:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi

I work for a company where we have not discontinued any of our FPGA modules, we are offering them as long the parts are available, module lifetimes 10+years.

https://wiki.trenz-electronic.de/display/TE0720/Overview

It is pretty standard zynq linux ready board. 
Marvell PHY, SMSC USB all standard. 
We do support our customers, also prototype level users.

It is maybe not visible on the website, but we have put a lot of effort into zynq development

https://wiki.trenz-electronic.de/display/TE0720/ARM+DS-5

this is how to debug and profile linux app on our board with free tools from ARM

I was surprised how painless that was. just write hello.c connect ETH cable and download run and profile it on zynq.


br
Antti Lukats




On Thursday, October 17, 2013 11:07:47 AM UTC+2, Tom Gardner wrote:
> On 17/10/13 09:31, MK wrote:
> 
> > You are taking a risk in basing a product on a development board - they aren't sold with that in mind and the suppliers don't see long term availability as part of the deal. There are quite  a lot of
> 
> > boards based on the Zynq around - eg: Mars ZX3- Zynq-7000 SO-DIMM module (which I have not used and don't recommend o not recommend.)
> 
> > You should be able to find a board with long term support and actually intended for OEM supply.
> 
> 
> 
> Thanks. Your points are well noted. Fortunately it
> 
> isn't actually for a product, only a prototype.
> 
> 
> 
> My concern is that I want/need decent documentation
> 
> and/or community support - and that might not be
> 
> there with a board that only has a very short
> 
> production life.
> 
> 
> 
> Fundamentally I want to grab my data, process it
> 
> and display it. I don't want to become an expert
> 
> in creating a linux for board Munge v0.9 using
> 
> tool Frobnatz v123.456!
> 
> 
> 
> Hence my questions about /which/ suppliers/toolsets
> 
> that people have found to be "reliable" by
> 
> the above definition.

Article: 155936
Subject: Re: Zynq devices, boards and suppliers
From: Paul Rubin <no.email@nospam.invalid>
Date: Thu, 17 Oct 2013 11:59:28 -0700
Links: << >>  << T >>  << A >>
Tom Gardner <spamjunk@blueyonder.co.uk> writes:
> 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.

I can't suggest any specific boards, but http://blog.elphel.com might be
of some interest.  Its last few entries are about a Zynq-based project.
Maybe posting to the blog's comment section will get some suggestions.

Article: 155937
Subject: Re: Zynq devices, boards and suppliers
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Thu, 17 Oct 2013 20:09:14 +0100
Links: << >>  << T >>  << A >>
Thank you for your pointer.

I have already bookmarked Trenz since I had seen a good
range of products there. The range looks like a justification
for your useful comment about modules' longevity.

I will dig around in the wiki to have a look at how the
tools would enable me to extend a helloworld.c program
to one that peeks/pokes my specific programmable logic
and also communicates over ethernet.



On 17/10/13 19:31, Antti wrote:
> Hi
>
> I work for a company where we have not discontinued any of our FPGA modules, we are offering them as long the parts are available, module lifetimes 10+years.
>
> https://wiki.trenz-electronic.de/display/TE0720/Overview
>
> It is pretty standard zynq linux ready board.
> Marvell PHY, SMSC USB all standard.
> We do support our customers, also prototype level users.
>
> It is maybe not visible on the website, but we have put a lot of effort into zynq development
>
> https://wiki.trenz-electronic.de/display/TE0720/ARM+DS-5
>
> this is how to debug and profile linux app on our board with free tools from ARM
>
> I was surprised how painless that was. just write hello.c connect ETH cable and download run and profile it on zynq.
>
>
> br
> Antti Lukats
>
>
>
>
> On Thursday, October 17, 2013 11:07:47 AM UTC+2, Tom Gardner wrote:
>> On 17/10/13 09:31, MK wrote:
>>
>>> You are taking a risk in basing a product on a development board - they aren't sold with that in mind and the suppliers don't see long term availability as part of the deal. There are quite  a lot of
>>
>>> boards based on the Zynq around - eg: Mars ZX3- Zynq-7000 SO-DIMM module (which I have not used and don't recommend o not recommend.)
>>
>>> You should be able to find a board with long term support and actually intended for OEM supply.
>>
>>
>>
>> Thanks. Your points are well noted. Fortunately it
>>
>> isn't actually for a product, only a prototype.
>>
>>
>>
>> My concern is that I want/need decent documentation
>>
>> and/or community support - and that might not be
>>
>> there with a board that only has a very short
>>
>> production life.
>>
>>
>>
>> Fundamentally I want to grab my data, process it
>>
>> and display it. I don't want to become an expert
>>
>> in creating a linux for board Munge v0.9 using
>>
>> tool Frobnatz v123.456!
>>
>>
>>
>> Hence my questions about /which/ suppliers/toolsets
>>
>> that people have found to be "reliable" by
>>
>> the above definition.


Article: 155938
Subject: Re: Zynq devices, boards and suppliers
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Thu, 17 Oct 2013 20:18:26 +0100
Links: << >>  << T >>  << A >>
On 17/10/13 19:59, Paul Rubin wrote:
> Tom Gardner <spamjunk@blueyonder.co.uk> writes:
>> 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.
>
> I can't suggest any specific boards, but http://blog.elphel.com might be
> of some interest.  Its last few entries are about a Zynq-based project.
> Maybe posting to the blog's comment section will get some suggestions.

Thanks for the pointer. Bookmarked.

A quick scan indicates some points that I don't feel are
relevant to me, and some which may or may not be once I've
read them more carefully.



Article: 155939
Subject: Re: reset strategy FPGA Igloo
From: alb <alessandro.basili@cern.ch>
Date: Fri, 18 Oct 2013 11:19:32 +0200
Links: << >>  << T >>  << A >>
Hi Rick,

On 16/10/2013 20:26, rickman wrote:
[]
>>> 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.
> 
> I'm not clear on this.  It sounds like you are using the timer in
> *place* of the lock signal from the PLL.  My point was to condition the
> lock signal from the PLL.  But since you say below that you don't know
> the state of the PLL lock signal at power up I suppose this won't work.
>  It would be a simple matter to test it though.  Or you can contact the
> factory.  Since there is no configuration process the logic of the PLL
> should be ready and working on power up I would expect.

The idea is to use the 'lock' signal *and* the timer. The lock signal
should be, at a certain point, signalling 'unlock' condition. This
condition, even if not reliable, allows the following logic:

1. use 'not lock' to set the global reset
2. start count when 'lock' is reporting 'pll locked' (unreliable) *and*
   the upper part of the count is correctly set to a certain pattern
3. count up until the maximum lock time specified in the datasheet
4. release the global reset

If 'lock' signals chatters at any stage of its life (that I suppose is
only happening when locking) does not matter, it will only mean the
counter will restart counting.

>> 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.
> 
> The fact that you are checking the upper bits prevents any pruning of
> the counter.  I think your approach is to help assure that the counter
> has been reset before it will count down.  I would not think this was
> workable.  Either the counter is reset properly or the circuit can
> malfunction by lockup, possibly with global_rst = '0'.  

I have to start from the assumption that my pll lock signal is, at a
certain stage, signalling a pll not in lock. If the pll lock signal
wrongly reports a pll not in lock is not an issue, while it is an issue
if it wrongly reports a pll in lock.

If the counter *is not* reset properly then a system lockup is at least
better than a logic that runs without a global reset.

> Also be aware
> that you are really only using 5 check bits since the sixth is used to
> flag end of timeout.

Correct, I did not really care how many bits I'm using in the example,
it was just to show the concept.

> 
> If this is a high rel application, I would not want to rely on a five
> bit checksum to control a reset. 

You have a point and, yes, I was too lazy to write the example in the
proper way.

> You say "guarantee" and "random", but
> I see the possibility that the counter starts up in the done state with
> reset never having been asserted, 1 in 64 chance.  If you check all the
> bits in the counter for the done state it is still a 1 in 4096 chance of
> malfunctioning without ever producing a reset out.
> 
> If you can't rely on the PLL lock signal to be asserted at power up, I
> don't think you can rely on *any* logic in the FPGA to compensate for
> this.  Why not investigate and find out if the PLL signal will work as a
> power on reset?  Contact the factory and/or test it yourself on the
> bench.  Bring the LOCK signal out to a pin and scope it while powering
> up the unit.

The investigation might be an extremely tedious process. Under which
conditions should I verify the behavior? Our temperature range is -40 +
80, should I run the test in all conditions? Should the test be
performed in thermovacuum (the application will run in low earth orbit).
In order to verify that the lock signal is correctly reporting a lock is
a not so straight forward path.

But I agree that relying on the fact that my pll lock signal is at least
reporting 'not locked' at a certain stage is still an assumption.

[]
> Even if you
> manage to supply a reset to all the FFs in your logic, is there nothing
> else on the chip that requires a reset like the PLL itself?  

PLL does not require an external reset.

> What other
> circuits are on the device other than the user configurable logic? 

there's a little bit of RAM and FLASH units. Not much indeed.

> Does
> the data sheet talk about a requirement for the reset signal?

Nope. Is up to the user to take care about meeting timing constraints.

> 
> The PLL issue and the idea of using the I/O pin to generate a reset are
> both issues I would contact the factory about.  

That is a good hint and I'm actually doing it. I'll try to report back
here at least to share the information with you all, somebody else might
find it useful.

> If I were in your shoes,
> I would push hard to have the module disqualified since the FPGA can not
> be assured to have been reset.  That is the part that is insanity!

I agree in principle, but pushing hard is not always beneficial and
being only a 'new comer' in the project I guess I do not have the
critical mass to push that hard.


Article: 155940
Subject: Re: Zynq devices, boards and suppliers
From: Antti <antti.lukats@gmail.com>
Date: Fri, 18 Oct 2013 02:53:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Tom,

we are working several projects that transfer data from ADC/DAC over ethernet.

In on case we converted existint application from Spartan6 to Zynq in a week, this included IP conversion and rewrite of C programs from baremetal to linux.

Antti



On Thursday, October 17, 2013 9:18:26 PM UTC+2, Tom Gardner wrote:
> On 17/10/13 19:59, Paul Rubin wrote:
> 
> > Tom Gardner <spamjunk@blueyonder.co.uk> writes:
> 
> >> 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.
> 
> >
> 
> > I can't suggest any specific boards, but http://blog.elphel.com might be
> 
> > of some interest.  Its last few entries are about a Zynq-based project.
> 
> > Maybe posting to the blog's comment section will get some suggestions.
> 
> 
> 
> Thanks for the pointer. Bookmarked.
> 
> 
> 
> A quick scan indicates some points that I don't feel are
> 
> relevant to me, and some which may or may not be once I've
> 
> read them more carefully.


Article: 155941
Subject: Re: Zynq devices, boards and suppliers
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Fri, 18 Oct 2013 16:02:22 +0100
Links: << >>  << T >>  << A >>
On 17/10/13 19:59, Paul Rubin wrote:
> Tom Gardner <spamjunk@blueyonder.co.uk> writes:
>> 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.
>
> I can't suggest any specific boards, but http://blog.elphel.com might be
> of some interest.  Its last few entries are about a Zynq-based project.
> Maybe posting to the blog's comment section will get some suggestions.

I've now had a more detailed look, and my initial comments
are unchanged.

Overall the October 2 entry (FPGA is for freedom) comes across
as a bit of a rant, but it does contain useful information.

The "uploads your design to Xilinx" for the zero cost toolset
is, of course, less than desirable. It is a valid way of filtering
out the commercial business from the free hobbyist sectors.

The claimed limitations of the software wizard for generating
the memory interface is not good news -- and is just the kind
of information I was hoping to elicit with my question. I would
be curious to know whether or not the tool accurately reflects
the silicon's capabilities.

The "DLL hell" (or linux equivalent!) is also bad news. Not
sure what the solution would be if I suffered the same problem.
Fortunately I have a newly-installed Xubuntu LTS, so it /ought/
to minimise the chance!

FSBL proprietary binary blob. I don't care if it is proprietary,
/provided/ it works correctly. To me it is merely an extension
of the config bitmap :)




Article: 155942
Subject: Re: Zynq devices, boards and suppliers
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Fri, 18 Oct 2013 16:22:30 +0100
Links: << >>  << T >>  << A >>
On 17/10/13 09:31, MK wrote:
> There are quite  a lot of
> boards based on the Zynq around - eg: Mars ZX3- Zynq-7000 SO-DIMM module (which I have not used and don't recommend o not recommend.)

Enclustra's attitude of "we'll show you this
documentation only /after/ you've become a customer"
doesn't endear them to me. But that's their
commercial decision.

They may be very good, but I would like to be able
to evaluate that for myself! Shame.


Article: 155943
Subject: Re: reset strategy FPGA Igloo
From: HT-Lab <hans64@htminuslab.com>
Date: Fri, 18 Oct 2013 17:59:27 +0100
Links: << >>  << T >>  << A >>
Hi Alb,

On 18/10/2013 10:19, alb wrote:
..
>
> The investigation might be an extremely tedious process. Under which
> conditions should I verify the behavior? Our temperature range is -40 +
> 80, should I run the test in all conditions?

yes!

>Should the test be
> performed in thermovacuum (the application will run in low earth orbit).

yes!

I suspect you didn't have your CDR yet but the first thing that was 
discussed when I was working on satellites was the reset/POR circuitry. 
I worked on OBC's during the Wire mission (1999) and hence reset/supply 
rise time/unused jtag pins etc were hot topics.

Regards,
Hans
www.ht-lab.com




Article: 155944
Subject: Re: reset strategy FPGA Igloo
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Fri, 18 Oct 2013 18:14:10 +0100
Links: << >>  << T >>  << A >>
On 18/10/13 10:19, alb wrote:
> Should the test be
> performed in thermovacuum (the application will run in low earth orbit).

I don't think the answer to that question will be left to chance!
(Nor its near equivalent, an answer in a usenet posting)


Article: 155945
Subject: Re: Zynq devices, boards and suppliers
From: Jon Elson <jmelson@wustl.edu>
Date: Fri, 18 Oct 2013 18:01:12 -0500
Links: << >>  << T >>  << A >>
Frank Buss wrote:

> 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:
> 
I know it doesn't have an FPGA, but if you need to add a board
to it for the outer interface, you should check out the Beagle
Board Black.  It has amazing capability and LOTS of varied I/O
pins, for $45!  Runs a complete Linux system, but can be used
"headless" (ie. no screen) easily.  Your added board can have
an FPGA or CPLD on it, if you are designing a board already,
it is quite easy if you won't be running at high clock speeds.
I do a bunch of CPLD and FPGA boards with only 2-sided PCBs.
I have even run Spartan 3A and 3AN FPGAs on 2-sided boards
with no trouble.

Jon

Article: 155946
Subject: Re: draw lines, circles, squares on FPGA by mouse and display on
From: =?ISO-8859-1?Q?Adam_G=F3rski?= <gorskiamalpa@wpkropkapl>
Date: Sat, 19 Oct 2013 17:16:28 +0200
Links: << >>  << T >>  << A >>
W dniu 2013-10-16 13:10, Herbert Kleebauer pisze:
> 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.
>
>
>

Have fun.

Adam

Article: 155947
Subject: Re: draw lines, circles, squares on FPGA by mouse and display on VGA ( not use NIOS)
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 19 Oct 2013 18:47:30 +0000 (UTC)
Links: << >>  << T >>  << A >>
ajbhavana89@gmail.com wrote:
> On Wednesday, 2 November 2011 17:25:33 UTC+10, lexuancong  wrote:

(snip)
 
>> 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.

The usual way to run a VGA display is in raster mode reading from
a display RAM. First write the code for that.

Then write code to load the appropriate shapes into memory.
(First clear it to background color.)

That should be a relatively simple state machine, though the easier
way is probably to build a simple processor and execute compiled
C code. (Or some other language.)

-- glen

Article: 155948
Subject: Re: draw lines, circles, squares on FPGA by mouse and display on VGA
From: Mawa_fugo <ccon67@netscape.net>
Date: Sat, 19 Oct 2013 17:53:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, November 2, 2011 2:25:33 AM UTC-5, 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 !


I think you need to turn in code, diagram, all in paper right?

If so you can do searchig on net, some folks here are really good help

On the basic, you need a cpu, a video frame buffer (sram, sdram, ...) that can hold let say 640 x 480 pixels vga...
And your FPGA is the center of this project, you use the fpga to glue all together and to make them to work

The cpu somehow needs to take the mouse input to generate pixel data and write it to the buffer  

On the other hand, the FPGA has to read the data out from the buffer in raster manner and display it on screen

anyway, this sounds a big project if you do it all by yourself, unless you already had some support

your professor must be the first one to ask...what have he taught you, what hints he can suggest, what evaluation board available etc...

 



   

Article: 155949
Subject: Re: Zynq devices, boards and suppliers
From: Paul Rubin <no.email@nospam.invalid>
Date: Sat, 19 Oct 2013 19:02:53 -0700
Links: << >>  << T >>  << A >>
Tom Gardner <spamjunk@blueyonder.co.uk> writes:
> I'd like to pick people's brains about aspects of
> different *suppliers* of Zynq boards. 

Do you know anything about the microzed?  I just heard of it, and it
looks interesting:

http://microzed.org
http://linuxgizmos.com/tiny-sbc-runs-linux-on-xilinx-zynq-arm-fpga/

Also the Zybo:

http://www.digilentinc.com/Products/Detail.cfm?Prod=ZYBO



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