Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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: 155926Hi, 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.comArticle: 155927
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: 155928On 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. -- RickArticle: 155929
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! -- RickArticle: 155930
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: 155931On 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
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, MarkArticle: 155933
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 KellettArticle: 155934
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
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
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
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
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
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
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
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
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
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.comArticle: 155944
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
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. JonArticle: 155946
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. AdamArticle: 155947
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.) -- glenArticle: 155948
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
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:
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