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
Patrick Dubois wrote: > Hello, > > Does anyone know of an example using lwIP in RAW mode with the > Virtex-4 temac? From what I understand, the lwIP temac port seemingly > only supports lwIP in sockets mode with xilkernel. > > I don't quite understand the lack of temac support at the software > level. What are people doing when using temac on the V4? Is everyone > using lwIP in sockets mode? No one is using raw lwIP on the V4? At X-Fest they said that raw mode will be available with EDK9.2, which is supposed to be available sometime after ISE9.2, which is scheduled for September, IIRC. -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...Article: 118876
>>>>>>>>>> derogatory crap deleted by archive ownerArticle: 118877
Fred Bloggs said: >>>>>>>>>> derogatory crap deleted by archive owner Well well well, another entry for the killfile. Racism is a clear sign of stupidity. Were stupidity curable by reason, that might be another matter, but it isn't, so it isn't. -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk email: rjh at the above domain, - www.Article: 118878
Richard Heathfield wrote: > Fred Bloggs said: > > >>>>>>>>>> derogatory crap deleted by archive owner > > Well well well, another entry for the killfile. Racism is a clear sign > of stupidity. Were stupidity curable by reason, that might be another > matter, but it isn't, so it isn't. > Stupidity is more often demonstrated by those who claim to see "a clear sign" all the time...Article: 118879
On Apr 29, 7:32 pm, Anson.Stugg...@gmail.com wrote:
> I'm designing a debounce filter using Finite State Machine. The FSM
> behavior is it follows the inital input bit and thinks that's real
> output until it receives 3 consecutive same bits and it changes output
> to that 3 consecutive bit until next 3 consecutive bits are received.
> A reset will set the FSM to output 1s until it receives the correct
> input and ouput.
>
> This is the test sequence with input and correct output.
>
> 1 0 0 1 0 1 0 0 0 1 0 1 1 1 (input)
> 1 1 1 1 1 1 1 1 0 0 0 0 0 1 (output)
>
> The state diagram I came up has 6 states and it's named SEE1, SEE11,
> SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
> the input. Because it just came from SEE1 and before SEE1, it came
> from SEE000, so at SEE1 it can not change ouput to 1 which is what I
> have specified that state's ouput to be.
>
> Anyone knows how to solve this problem? Or maybe there's other better
> ways to design the state diagram?
Just describe the states in C first: "output" is the debounced output
value; "contradictions" is the number of bits that were input that
could convince you to switch the output state.
int output = 1; // 0 or 1
int contradicitions = 0; // 0, 1, or 2
for (;;) {
int input = get_input ();
if (input == output) contradictions = 0;
else if (contradictions < 2) ++contradictions;
else { output = input; contradictions = 0; }
}
Clearly there are six states; fill in the transitions according to
what the algorithm does.
Article: 118880
Tom wrote:
> I don't have experience with MyHDL, so my statements may need to be
> qualified. From what
> I gather, MyHDL very closely approximates the semantics of Verilog
> (@always(clock.posedge)).
VHDL semantics actually, where it really matters (i.e. a clear
separation between Signal objects and plain variables.)
> Therefore I suspect, in terms of synthesis, MyHDL is still at RTL.
>
> Where MyHDL shines, is it's ability to simulate within it's host
> language, Python.
> If locked in a room with SystemVerilog and Python, I'd take Python any
> day. If offered
> OCaml or Haskell, I'll always reach for higher-order functional
> languages.
I believe that the usage of the term "RTL" creates a lot of confusion,
as I hope to clarify below.
The way I see it, there are two schools of thought in HDLs, depending
on the way they treat events and (hardware) registers:
* Type 1: explicit registers & implicit events
HDLs based on functional languages seem the be all of this type.
* Type 2: explicit events & implicit registers
This is the model of HDLs such as VHDL and Verilog (and MyHDL).
VHDL signals and variables, and Verilog regs, are all objects
that may become registers, or not, in hardware, depending on
how they are used in the code. Thus, registers are implicit.
Regarding the term RTL - Register Transfer Language - it seems clear
that it's appropriate terminology for type 1 languages. But how
could it be meaningful for type 2 languages - languages
without "register objects"?
It might even be argued that type 2 languages concentrate more
on hardware behavior instead of implementation, and therefore
should be considered "higher level".
More interestingly, there seems to be correlation between the
language type and the kind of semantics provided. Clearly,
all HDLs need concurrent statements - such as VHDL processes
and Verilog always blocks. However, type 1 languages seem
to stop there, while type 2 languages provide sequential
statements also (inside processes and always blocks).
So in my view, type 2 semantics is a superset of type 1.
Type 2 is more successful simply because it is more
powerful.
Jan
--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com
Article: 118881Jan Decaluwe wrote: > It might even be argued that type 2 languages concentrate more > on hardware behavior instead of implementation, and therefore > should be considered "higher level". I agree. Inside a synchronous block/process of a Type 2 RTL description, I can be as procedural as I like. Synthesis will take care of the pesky details of inferring the LUTs, registers, and those wires to hook them up. However, when it comes to wiring up blocks and modules, my procedural inclinations are thwarted. I'm ready for Type 3. -- Mike TreselerArticle: 118882
> > I believe that the usage of the term "RTL" creates a lot of confusion, > as I hope to clarify below. > > The way I see it, there are two schools of thought in HDLs, depending > on the way they treat events and (hardware) registers: > > * Type 1: explicit registers & implicit events > HDLs based on functional languages seem the be all of this type. > > * Type 2: explicit events & implicit registers > This is the model of HDLs such as VHDL and Verilog (and MyHDL). > VHDL signals and variables, and Verilog regs, are all objects > that may become registers, or not, in hardware, depending on > how they are used in the code. Thus, registers are implicit. > > Regarding the term RTL - Register Transfer Language - it seems clear > that it's appropriate terminology for type 1 languages. But how > could it be meaningful for type 2 languages - languages > without "register objects"? I think it is. For hardware that is actually synthesizable, there are really only two standard event models which are useful: always @* always @(posedge clock[, posedge reset]) Thus we still only really have combinatorial or registered logic. It strikes me as more confusing than useful that "regs" or "signals" (or "variables") can be both. The one grey area is describing latches. In all my FPGA designs I have never (intentionally) used them. In the one ASIC project I worked on that did allow them, they had to be instantiated as a library component which is easily supported by most HDLs. > > It might even be argued that type 2 languages concentrate more > on hardware behavior instead of implementation, and therefore > should be considered "higher level". > What in particular do think makes it higher level? At the end of the day we still only desribe one of two things - combinatorial logic or registers. The only difference is in type 1 is it defined when the "object" is created and in type 2 it is inferred from it's environment. The later seems more clumsy to me. > More interestingly, there seems to be correlation between the > language type and the kind of semantics provided. Clearly, > all HDLs need concurrent statements - such as VHDL processes > and Verilog always blocks. However, type 1 languages seem > to stop there, while type 2 languages provide sequential > statements also (inside processes and always blocks). > I agree that the sequential style of coding is useful, however, it is available in both HDCaml and HDFS. In fact the model provided there is, in my opinion, more powerful than VHDL and Verilog (I dont know about MyHDL) as the constructs can be manipulated programatically by the host language. The abstraction provided by atom is a whole different kettle of fish which significantly changes the way you think about circuit design. Of all the HDLs mentioned so far it's the only one I consider can truly be called "higher level". Please dont for a second consider this any sort of criticism of MyHDL - it's a very good idea with a great implementation. For my part, however, I prefer the functional programming approach - I just wish more people agreed... Cheers, Andy.Article: 118883
Hi having trouble :(, all Xilinx and example only explain the used of OPB_SPI as master, as slave it doesnt want to work, any tricks or special care required? AnttiArticle: 118884
On May 3, 1:37 am, chakra <narashim...@gmail.com> wrote: > Hello all, I am working on a project, in which am trying to make > OV7660 camera protoboard to talk to ML300 Xilinx FPGA board.I have a > general question regarding OPB bus. > > Here is the set up: I am building a OPB Master peripheral which > directly talks to camera (8 data, vsync, Href and Pixclk) via GPIO > pins on the ML300 board. The same master peripheral talks to OPB DDR > SDRAM which is a slave connected to the OPB Bus. the Master peripheral > acquires the data from the camera frame after frame and stores them in > the DDR(currently am overwriting the image over and over at the same > address stack in DDR) > > Question:: is there a limitation in terms of "clock cycles" to hold > the M_Select/M_Buslock high when given OPB_Mgrant by the opb BUS. Like > for example "..on a particular time once the OPB gives M_Grant a > Master peripheral can hold the M_Select and M_Buslock high only for > 16 clock cycles...". is there some limitation like the above? > > i am holding the M_Buslock and M_Select high till the transfer is > complete. and it takes close to 640*480*2 pixclk to collect one frame > of data from the camera to DDR SDRAM. Once the transfer is complete I > do release those signals and pull M_Dbus to ground. I read through the > Buslock operation given in the OPB manual by IBM and they seem to be > vague on this issue. > > algorithm might look like this > A. Master peripheral holds M_Request high > B. OPB gives OPB_Mgrant > C. Master peripheral pulls M_Request low and holds M_select high to > assert OPB bus and take control of the bus. and once transfer is done > D. Master peripheral pulls M_Select Low > > If you can help me in this regard it will be very helpful for the > success of my project Dear Chakra, I build a peripheral like this about a year ago. The principle is about the same what you suggested, you just forgot some details: A. Master peripheral holds M_Request high B. OPB gives OPB_Mgrant C. Master peripheral pulls M_Request low and holds M_select, M_seqAddr, M_BE and M_busLock high to assert OPB bus and take control of the bus. You should increment address for every OPB_xferAck received. D. One cycle before the end of burst pull the M_seqAddr and M_seqAddr low E. Master peripheral pulls M_Select and M_BE Low There is NO limitation for burst size in clock cycles. The only thing which limits the burst size is a OPB_retry signal which is asserted after OPB_xferAck going low. This is usually a consequence of RAM refresh. When the OPB_retry happens in the state C then cancel transfer and retry (state A). If you receive OPB_errAck or OPB_timeout then immediatelly cancel transfer. Don't hesitate to contact me for further questions. Good luck, GuruArticle: 118885
evilkidder@googlemail.com wrote:
> For hardware that is actually synthesizable, there are
> really only two standard event models which are useful:
>
> always @*
> always @(posedge clock[, posedge reset])
>
> Thus we still only really have combinatorial or registered logic. It
> strikes me as more confusing than useful that "regs" or "signals" (or
> "variables") can be both.
I have two points to add to the confusion:
* the form "always @(posedge clock[, posedge reset])" is not just for
registered logic, but for combinatorial logic as well. With a few exceptions,
it's probably the only template that you really need.
* it's not just that one variable can be combinatorial and another registered;
to make things worse :-) the *same* variable can be *both*!
For a practical example (in MyHDL) on how this can be useful, see:
http://myhdl.jandecaluwe.com/doku.php/cookbook:jc2
How to solve the confusion? Replace the "Think hardware" paradigm with
"Understand your compiler" (the compiler being the synthesis tool).
Similar to what good software engineers do, you have to understand what
type of coding styles are handled efficiently by the compiler, even if
at first you don't exactly understand how.
Once you do that the confusion disappears and a whole new world of
elegant coding solutions becomes available. And you even start to
understand how the compiler works - it's not *that* hard after all :-)
Jan
--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com
Article: 118886On May 3, 8:25 am, Frank Buss <f...@frank-buss.de> wrote: > Would be a good idea to combine both designing tools (but using the GUI of > Quartus, because it's nicer than the ISE GUI) and open source it. In the > end this would lead to less development cost for all: the FPGA companies, > because they don't need to write both the same things and for users of the > program, because they can help bugfixing it and using a more stable > program. Company secrets could be moved to plugin modules. When their management learn the products can be supported better with the same number of people leading the project, and the developers learn they are not likely to lose their jobs, it should be an easier decision. Plus they get aditional volunteer labor for design, coding, AND TESTING that they can not afford now. Even large customers, which have significant internal development staff see less project risks when they can fix mission critical bugs on the fly, rather than have the whole project grind to a stop while pressing the vendor hard for a fix. Another benefit, is recruiting new hires can be taken from the volunteer developer pool as needed, and they are already several months ahead of the learning curve that it takes to get a new hire productive. It's hard sometimes to understand why they think remaining in the stone age is better.Article: 118887
On May 5, 4:41 am, Edmond Cot=E9 <edmond.c...@gmail.com> wrote:
> On May 4, 12:47 am, Tom <tomahawk...@gmail.com> wrote:
>
> > Atom is a new high-level hardware description language embedded in
> > the functional language Haskell. Atom compiles circuit descriptions
> > in conditional term rewriting systems down to Verilog and VHDL
> > for IC simulation, verification, and synthesis.
>
> I'll take a look...
>
> Sounds a lot like Bluespec, what can you say about the differences
> between the two?
>
> Edmond
The ideas are the same, but Atom lags behind Bluespec on nearly every
front. Atom has:
- no support for multiple clock domains
- no assertions
- no input language support for SystemVerilog or SystemC
- incomprehensible HDL code generation
- minimal circuit optimization
- limited design capacity
If you are looking for a behavioral synthesis tool for professional
grade ASIC design, Bluespec is the best choice on the market. But if
you're a hobbyist without a CAD budget, Atom provides a glimpse of the
future of IC design.
-Tom
PS: This is just speculation, but Atom's rule scheduling may be
significantly different Bluespec -- I see no mention of it in the MIT
research papers. For those interested, Atom assigns a global, linear
priority to rules. To maximize rule concurrency, Atom prioritizes the
rules to minimize the number of lower priority rules that write data
read by higher priority rules. When a higher
priority rule writes data read by a lower priority rule, but not vice
versa, this forms a "sequentially composable" relationship, and
thus the two rules can execute in the same clock cycle. In this
framework, rule scheduling becomes equivalent to the Feedback Arc Set
problem (http://en.wikipedia.org/wiki/Feedback_arc_set), where an arc
is a data dependency between two rules.
Unfortunately, many of the arcs in a rule-data dependency graph are
irrelevant, since some rules can not be enabled at the same time. For
example, take an FSM, where the FSM is modeled with one rule for every
state:
stoplightController :: System ()
stoplightController =3D do
state <- reg "state" 2 0
let red =3D constant 2 0
yellow =3D constant 2 1
green =3D constant 2 2
rule "onRed" $ do
when (value state =3D=3D. red)
...
state <=3D=3D green
rule "onGreen" $ do
when (value state =3D=3D. green)
...
state <=3D=3D yellow
rule "onYellow" $ do
when (value state =3D=3D. yellow)
...
state <=3D=3D red
For the stoplightController, the onRed, onGreen, and onYellow rules
will never be enabled at the same time. Therefore, any arcs between
these rules should be removed from the rule-data dependency graph
before optimizing the schedule. To find these mutually exclusive
rules, Atom analyzes the rule logic with it's own algorithms and with
the help of the MiniSat external SAT solver. There's no guarantee it
finds all mutually exclusive rules, but it does a pretty good job.
Article: 118888On May 4, 2:27 am, Francesco <francesco_poder...@yahoo.com> wrote: > I will post in this forum the name of the domain Any thoughts about merging this work with http://sourceforge.net/projects/sdcc/ to leverage maintainence and provide cross device protability for libraries, applications, and tools?Article: 118889
On Sat, 05 May 2007 11:52:30 -0700, evilkidder@googlemail.com wrote:
> What in particular do think makes it higher level? At the end of the
> day we still only desribe one of two things - combinatorial logic or
> registers. The only difference is in type 1 is it defined when the
> "object" is created and in type 2 it is inferred from it's
> environment. The later seems more clumsy to me.
I would tend to agree. I have been working on a HDL (which is stalled
because some aspects of it don't scale well!) but explicitly declaring
registers is something that I like. From my stuff:
reg myRegister[%8]; # an eight bit register
reg myRegister[%8] = dataIn when load; # loadable register
reg myCounter[%8] = next; # 8-bit binary counter that just counts up
reg myCounter[%8] = { next when up; prev when dn; } # up/dn counter
gray myCounter = next; # gray counter that just counts up
johnson myCounter = { 0 when rst; next when up; } # guess what it does?
onehot myCounter = { async 0 when rst; next when up; } # ditto
shift reg myShReg[%8] = next when shft with myShReg[0] = serialIn; # ditto
Finally an example that creates two counters which are incremented in
different states of a state machine:
# the two counters
reg myCounterA[%4], myCounterB[%8] = { node up; next when up; }
# the state machine
reg myStateMachine[] = {
: myCounterA.up = 1; next;
: myCounterB.up = 1; prev;
}
Regards,
Paul.
Article: 118890
On Sun, 06 May 2007 18:57:14 +0100, Paul Taylor wrote:
too hasty in posting....
> gray myCounter = next; # gray counter that just counts up
> johnson myCounter = { 0 when rst; next when up; } # guess what it does?
> onehot myCounter = { async 0 when rst; next when up; } # ditto
should be as:
gray reg myCounter[%4] = next;
johnson reg myCounter[%4] = { 0 when rst; next when up; }
onehot reg myCounter[%4] = { async 0 when rst; next when up; }
gray, johnson, onehot provide context for the next and prev keywords
(amongst other things)
Regards,
Paul.
Article: 118891I have a differential driver with Vcm = 3.025V and Differential voltage of 1100mv. Thus each arm of the differential signal has 550 mV swing and Vcm being Vcc - 0.275V (3.3 - 0.275 = 3.025V). Looking at the V5 LVPECL input specification, the Vicm can cary from 0.6V to 2.2V. This does not match with the Non Xiilnx output driver with Vcm = 3.025V Is there any way I can ake this work without adding external termination? Thanks for your valuable feedback. Test01Article: 118892
On May 6, 12:25 pm, Test01 <cpan...@yahoo.com> wrote: > I have a differential driver with Vcm = 3.025V and Differential voltage of 1100mv. Thus each arm of the differential signal has 550 mV swing and Vcm being Vcc - 0.275V (3.3 - 0.275 = 3.025V). > > Looking at the V5 LVPECL input specification, the Vicm can cary from 0.6V to 2.2V. This does not match with the Non Xiilnx output driver with Vcm = 3.025V > > Is there any way I can ake this work without adding external termination? > > Thanks for your valuable feedback. > > Test01 You claim that the output voltage , at its most positive, is 275 mV more positive than its Vcc. Can that be true? Peter Alfke, from homeArticle: 118893
Test01 wrote: > I have a differential driver with Vcm = 3.025V and Differential voltage of 1100mv. Thus each arm of the differential signal has 550 mV swing and Vcm being Vcc - 0.275V (3.3 - 0.275 = 3.025V). > > Looking at the V5 LVPECL input specification, the Vicm can cary from 0.6V to 2.2V. This does not match with the Non Xiilnx output driver with Vcm = 3.025V > > Is there any way I can ake this work without adding external termination? > > Thanks for your valuable feedback. > > Test01 Your non-Xilinx drivers aren't LVPECL, are they? What is your driver? Does its common-mode range have to be so high?Article: 118894
Hi all, sorry for the confusion, anyway to answer any doubts, the said demo was the one as described by Eric Crabill where you can edit the picture from the camera on the video display. The hardware used is also as described by Eric. This design i am not sure why is it not posted yet. Well i do work in Xilinx Asia Pacific and i have posted internal tech support as well but no reply yet. Also I did not see this demo at XFEST , rather tomorrow is XFEST @ Singapore and I am manning the booth, so that is why i sound so troubled and urgent. Meanwhile i have contacted faes and sales rep as well so hopefully it will all work out. (P.S: I am not that well versed in FPGA system level design yet, just a newbie) "Antti" <Antti.Lukats@xilant.com> wrote in message news:1178345956.666826.284270@q75g2000hsh.googlegroups.com... > Eric Crabill schrieb: >> Hi Jim, >> >> I don't usually look at the message headers, because it plays no role in >> my >> deciding to answer a question. Maybe Bryan does work with/for Xilinx! >> In >> any case, Bryan, I hope I answered your question. >> >> You can get a working DDR2 interface from MIG 1.7 specifically for the >> Spartan-3A Starter Kit. There's also a working design derived from that >> in >> the board test design that is posted on the Spartan-3A Starter Kit >> reference >> design page. I think what some previous posters wanted was more than >> "working", rather a "stress test" or something that really demonstrates >> the >> bandwidth of the memory interface. I agree that such a demo or reference >> design would have value. Do I have any comments/release schedules to >> share? >> No, sorry. >> >> Eric >> >> "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message >> news:463b885f$1@clear.net.nz... >> > Eric Crabill wrote: >> >> Hi Bryan, >> >> >> >> Maybe you saw the video pass through design at an XFEST event or at >> >> the >> >> Spartan-3AN press release event? Otherwise, I am not sure how you >> >> would >> >> know it exists. If you are looking for that design, please contact >> >> your >> >> local FAE or sales representative for assistance. I am not sure >> >> if/when >> >> this design will be posted. >> > >> > :) Err.., I think he IS the local FAE / Sales rep, as his address >> > claims >> > Xilinx ?. >> > >> > It maybe that it was an 'oops' posting, meant to go upstream inside >> > Xilinx. [yes, does happen sometimes...] >> > >> > Any comments/release schedules re Antti's questions about DDR2 working >> > examples on 3A demo system ? >> > >> > -jg >> > > > Eric, > > it looks like I am missing something :( > > 1) the only thing at X-Fest was the rotazoom that takes images from > NOR flash > no video pass through demo (at X-Fest in Munich) > > 2) the only "derived" DDR2 design seems to be board test design where > PicoBlaze > reads out the MIG testbench error led status and displays p or f on > hyperterminal - > is this the MIG derived design you have been referreing to, or is > there some more > functional design available? > > Antti >Article: 118895
> the only "derived" DDR2 design seems to be board test design where > PicoBlaze reads out the MIG testbench error led status and displays > p or f on hyperterminal is this the MIG derived design you have been > referreing to Yes.Article: 118896
On 7 Mai, 04:43, "Bryan" <s...@xilinx.com> wrote: > Hi all, sorry for the confusion, anyway to answer any doubts, the said demo > was the one as described by Eric Crabill where you can edit the picture from > the camera on the video display. The hardware used is also as described by > Eric. This design i am not sure why is it not posted yet. Well i do work in > Xilinx Asia Pacific and i have posted internal tech support as well but no > reply yet. Also I did not see this demo at XFEST , rather tomorrow is XFEST > @ Singapore and I am manning the booth, so that is why i sound so troubled > and urgent. Meanwhile i have contacted faes and sales rep as well so > hopefully it will all work out. > > (P.S: I am not that well versed in FPGA system level design yet, just a > newbie) Hi dont worry so much - when I was at X-Fest munich then the first question I asked at Spartan-3A booth: "may i see the DNA demo?" caused the support personal to seek for printed documents and reading them (means they had not done their homework). While seeing the S3A board first time I figured out the way to start the DNA demo before the support personel found it the printed documents. So it is good that you are trying todo your homework ahead of time, it may avoid trouble with difficult questions at the booth. I hope that you do not get trouble asking a "xilinx internal support question" at public newsgroups, as in many times c.a.f. can deliver results WAY faster then Xilinx WebCase. sidenote to Xilinx: there is room for improvment for information flow within Xilinx? (To improve the ability of Xilinx employees to support Xilinx customers) AnttiArticle: 118897
On 2 May 2007 06:21:32 -0700, Antti <Antti.Lukats@xilant.com> wrote: >After giving up the search for Xilinx supplied MicroBlaze reference >designs for Xilinx Spartan-3A kit, I made the reference design using >BSB in EDK 9.1SP1. > >No problem encountered until the attempt to load the bitstream into >Spartan-3A > >Bitstream download succeeded, Done also OK. >Reading back JTAG Status from impact tells me EVERYTHING is OK! > >But... init LED is half-way dimmed and "AWAKE" LED is off, this >behavior is the same no matter the "SUSPEND" input switch position. I >have not enabled suspend in the design, so to my understanding the >bitstream should come up alive? > >But it doesnt. Is Spartan-3A in some undocumented deep sleep mode? > >I was really hoping to see "Hello Spartan-3A" on the terminal, or at >least the LEDs blinking. >But all that happens is DONE=ON, AWAKE=OFF, INIT=30% dimmed. > >I will fight again tomorrow, maybe I get some bright how to wake up >Spartan-3A when I sleep. > >Antti I am working with S3ASK, with microblaze and have no problema at all. Maybe you forgot to set the configuration switches to JTAG? I had that problem too! Best regards zaraArticle: 118898
On 7 Mai, 09:41, Zara <me_z...@dea.spamcon.org> wrote: > On 2 May 2007 06:21:32 -0700, Antti <Antti.Luk...@xilant.com> wrote: > > >After giving up the search for Xilinx supplied MicroBlaze reference > >designs for Xilinx Spartan-3A kit, I made the reference design using > >BSB in EDK 9.1SP1. > > >No problem encountered until the attempt to load the bitstream into > >Spartan-3A > > >Bitstream download succeeded, Done also OK. > >Reading back JTAG Status from impact tells me EVERYTHING is OK! > > >But... init LED is half-way dimmed and "AWAKE" LED is off, this > >behavior is the same no matter the "SUSPEND" input switch position. I > >have not enabled suspend in the design, so to my understanding the > >bitstream should come up alive? > > >But it doesnt. Is Spartan-3A in some undocumented deep sleep mode? > > >I was really hoping to see "Hello Spartan-3A" on the terminal, or at > >least the LEDs blinking. > >But all that happens is DONE=ON, AWAKE=OFF, INIT=30% dimmed. > > >I will fight again tomorrow, maybe I get some bright how to wake up > >Spartan-3A when I sleep. > > >Antti > > I am working with S3ASK, with microblaze and have no problema at all. > Maybe you forgot to set the configuration switches to JTAG? I had that > problem too! > > Best regards > > zara- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - nono - there was NO PROBLEM..:) I was just confused that with default setting the INIT LED is 50% on state.. this is however NORMAL behaviour, I did not recognize that, and assumed something was wrong. all things work ok on s3astarter, including MicroBlaze - well without DDR2 support :( AnttiArticle: 118899
If i have an external SPI FLASH connected to the FPGA and uses 'Disable Readback' in the configuration. What does it do exactly? It is still possible to read the SPI FLASH externall?
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