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
rickman wrote: <snip> > It just occured to me that I really don't need to know the format of > the data if I just treat the signals as arbitrary data streams. I can > sample them at high enough rates that the timing information is not > significantly distorted and send them across in a very, very simple > scheme. I can sample each one in a round-robin manner at say 1 MHz for > a total clock rate of 10 MHz (10 signals in one direction, 2 in the > other). This interface would need a clock, datain, dataout and frame > sync. If you use Sync related direction control ( see SPI memories ), you can share/common the datain/dataout : eg the first 12 clocks are one way, the last 4 are the other way, in a simple 16 clock frame, with spare room ) -jgArticle: 106451
Hi, Forget this, my missunderstanding. /michaelArticle: 106452
>> Or a bus specification that counts down the number of >> wait states ;-) > > The problem with both is that it would impose undesirable constraints on slaves. Imagine the case of a good SDRAM controller which > tracks open pages. Read latency depends on what it's currently doing (idle, refreshing, busy with another request, etc) and > whether the access hit on open page. In this case it _could_ perhaps give an early "read-data-in-2-cycles" strobe, but dealing > with that would be a nasty complication for the interconnect structure that has to be able to handle any combination of > multi-masters and random assortment of slaves. If the interconnction of multiple masters gets too complicated the information can still be ignored. Than it's the same as with a single ready signal. However, there is a benefit for single master accessing a varibale latency slave (your SDRAM example). > FWIW, I used to do exactly what you suggest (latch and mux), but it didn't scale for me as the interconnection grew and was > expensive in both resources and cycle time (not to mention the added complication and one more argument in a single cycle command with register in the slave ;-) >> BTW: Did you take a look into the SimpCon idea? > > I just did, after writing the above :-), but my point still stands. AFAICT, SimpCon doesn't support multiple outstanding requests > from any one master and therefore doesn't distinguish between being able to accept a new request and and being done with a > request. It can do the same pipelining requests as Avalon. With a small difference. Take the SDRAM as example: It has a long initial latency and then incremental words can follow fast. With Avalon you can issue several (depends on the slave pipeline) requests and than you have to wait. In SimpCon you issue the first request then you have to wait for the latency and the following requests are faster. For this example it's just different when the latency wait occours: at the beginning (SimpCon) or later. The first word latency is the same and the following reads are the same. > I'm sure SimpCon works for you, but for me it would be not much better than Wishbone. No, both Avalon and SimpCon can handle pipelined (in order) requests. Wishbone not. Out-of-order compeltion of requests is a complete different story. I don't see usage for this at the moment for a 'normal' CPU master. > >> Dreaming a little bit: Would be cool to write an >> open-source system generator (like SOPC builder) for >> it. Including your suggestion of an open and documented >> specification file format. > > Sure, though I suspect writing all this would be trivial compared to coming to an agreement on how the interface should work :-) I agree! As Tanenbaum said, "The nice thing about standards is that there are so many to choose from". MartinArticle: 106453
>
>>> Yes, but e.g. for an SRAM interface there are some timings in ns. And
>>> it's not that clear how this translates to wait states.
>>
>> Since Avalon is not directly compatible the typical SRAMs, this implies
>> that
>
> Again disagree ;-) The Avalon specification also covers asynchronous
> peripherals. That's adds to a little bit to the complexity of the
> specification.
>
No, the Avalon specification is completely synchronous and is not directly
compatible with any of the garden variety asynchronous SRAMs that I'm aware
of. Just because you can add a controller that is compatible with the
synchronous Avalon bus on one side and an asynchronous SRAM on the other
does not imply anything at all about Avalon, it just says that one can make
a controller that will provide that interface. The same can be said about
interfacing Avalon to any other peripheral too so there is nothing special
about SRAMs and Avalon.
>> Assuming for the moment, that you wanted to write the code for such a
>> component, one would likely define that the component to have the
>> following:
>> - A set of Avalon bus signals
>> - SRAM Signals that are defined as Avalon 'external' (i.e. they will get
>> exported to the top level) so that they can be brought out of the FPGA.
>> - Generic parameters so that the actual design code does not need to hard
>> code any of the specific SRAM timing requirements.
>
> Yes, that's the way it is described in the Quartus manual. I did my
> SRAM interface in this way. Here is a part of the .ptf that describes
> the timing of the external SRAM:
>
> SLAVE sram_tristate_slave
> {
> SYSTEM_BUILDER_INFO
> {
> ....
> Setup_Time = "0ns";
> Hold_Time = "2ns";
> Read_Wait_States = "18ns";
> Write_Wait_States = "10ns";
> Read_Latency = "0";
> ....
>
>> Given that, the VHDL code inside the SRAM controller would set it's
>> Avalon side wait request high as appropriate while it physically performs
>> the
>
> There is no VHDL code associated with this SRAM. All is done by the
> SOPC builder.
>
Are we talking about interfacing with a synchronous SRAM or an async SRAM?
If it's a synchronous SRAM than I agree the Avalon signal set is likely
compatible but if it's the garden variety async SRAM where timings are
measured relative to edges of WR and RD than what you have won't work
reliably in the real world.
>> read/write to the external SRAM. The number of wait states would be
>> roughly equal to the SRAM cycle time divided by the Avalon clock cycle
>> time.
>
> The SOPC builder will translate the timing from ns to clock cycles for
> me. However, this is a kind of iterative process as the timing of the
> component depends on tco and tsu of the FPGA pins of the compiled design.
> Input pin th can usually be ignored as it is covered by the minimum tco
> of the output pins. The same is true for the SRAM write th.
>
The above is again making me think that we're talking about interfacing to
an async SRAM. If that's the case, then from your description it sounds
like Avalon address/read/write basically become the corresponding signals on
the SRAM. If that's the case, then how are you guaranteeing that the
address is stable at the SRAM prior to write being asserted and after it has
been de-asserted. The way the Avalon address and write signals work they
will both be transitioning some Tco after the rising edge of the clock.
There is absolutely no guarantee of any timing relationship between address
and write on the Avalon side, so if those are brought out unmodified to the
SRAM you have no guarantee there either....but for an async SRAM you
absolutely have to have that. If address and write are nominally
transitioning at the 'same' time then you won't get reliable operation (or
if you build enough of these they will 'erratically' fail) because you can't
guarantee that you've met the timing requirements of the SRAM.
>> Although maybe it sounds like a lot of work and you may think it results
>> in some sort of 'inefficient bloat' it really isn't. Any synthesizer
>> will quickly reduce the logic to what is needed based on the usage of the
>> design. What you get in exchange is very portable and reusable
>> components.
>
> No, it's really not much work. Just a few mouse clicks (no VHDL) and the
> synthesized result is not big. The SRAM tristate bridge contains just
> the address and control output registers. I assume the input registers
> are somwhere burried in the arbitrator.
>
Actually I was referring to what I had described as not being that much
work. I agree that what you've done doesn't take much work but I also don't
think that your 'sram_tristate_slave' component will work reliably if used
to interface with an external asynchronous SRAM. It probably will work if
you're interfacing it to a synchronous SRAM if you also then bring out the
Avalon clock as the SRAM clock.
I guess this also answers why you're seeing that the master device is
basically 'stuck' with wait requests until the SRAM operation has been
completed. The reason is because you as the designer of the
'sram_tristate_slave' component did not provide any code to support
registering the control signals yourself inside your component (inside the
VHDL that doesn't exist). Had you done this, you would've been able to
design a component that would allow the master to continue on while the SRAM
operation is still in progress. The only time the master would then need to
be stalled is if it performed a subsequent access to the SRAM while the
previous one was still in progress.
KJ
Article: 106454
>> Yes, that's the way it is described in the Quartus manual. I did my
>> SRAM interface in this way. Here is a part of the .ptf that describes
>> the timing of the external SRAM:
>>
>> SLAVE sram_tristate_slave
>> {
>> SYSTEM_BUILDER_INFO
>> {
>> ....
>> Setup_Time = "0ns";
>> Hold_Time = "2ns";
>> Read_Wait_States = "18ns";
>> Write_Wait_States = "10ns";
>> Read_Latency = "0";
>> ....
>>
>>> Given that, the VHDL code inside the SRAM controller would set it's Avalon side wait request high as appropriate while it
>>> physically performs the
>>
>> There is no VHDL code associated with this SRAM. All is done by the
>> SOPC builder.
>>
> Are we talking about interfacing with a synchronous SRAM or an async SRAM? If it's a synchronous SRAM than I agree the Avalon
> signal set is likely compatible but if it's the garden variety async SRAM where timings are measured relative to edges of WR and
> RD than what you have won't work reliably in the real world.
It's async. SRAM. And I just did what is described in the Quartus
manual. If that is not reliable then Altera should update the manual.
> The above is again making me think that we're talking about interfacing to an async SRAM. If that's the case, then from your
> description it sounds like Avalon address/read/write basically become the corresponding signals on the SRAM. If that's the case,
> then how are you guaranteeing that the address is stable at the SRAM prior to write being asserted and after it has been
> de-asserted. The way the Avalon address and write signals work they will both be transitioning some Tco after the rising edge of
> the clock. There is absolutely no guarantee of any timing relationship between address and write on the Avalon side, so if those
> are brought out unmodified to the SRAM you have no guarantee there either....but for an async SRAM you absolutely have to have
> that. If address and write are nominally transitioning at the 'same' time then you won't get reliable operation (or if you build
> enough of these they will 'erratically' fail) because you can't guarantee that you've met the timing requirements of the SRAM.
As I set setup time to 0ns, you're right. There is a little issue (depends
on the tco of the different pins) when wrn goes low before the address
is stable. That's against the SRAM timing spec. (minimum wrn low after
address is 0ns). However, I 'assume' that this does not matter. Setting
Setup_Time to something >0ns will add one additional cycle.
To avoid this little issue and the additional cycle I do usually (with
my SimpCon SRAM controller) clock the nwr with the inverted clock to
shift it after address setup.
> Actually I was referring to what I had described as not being that much work. I agree that what you've done doesn't take much
> work but I also don't think that your 'sram_tristate_slave' component will work reliably if used to interface with an external
> asynchronous SRAM. It probably will work if you're interfacing it to a synchronous SRAM if you also then bring out the Avalon
> clock as the SRAM clock.
Ok, again - it was a first try and do it as described by Altera. However,
the next step will be a 'real' SRAM slave. With the nwr trick as described
and with timing (wait states) given in clock cycles as parameter.
> 'sram_tristate_slave' component did not provide any code to support registering the control signals yourself inside your component
> (inside the VHDL that doesn't exist). Had you done this, you would've been able to
That's an option in the tristate bridge ;-) However, I assume that this means
only register the ouput to get a low tco.
> design a component that would allow the master to continue on while the SRAM operation is still in progress. The only time the
> master would then need to be stalled is if it performed a subsequent access to the SRAM while the previous one was still in
> progress.
Not for the read (in my case) as I'm waiting for the read data in the
processor. In some cases I can hide the latency by execution of additional
code. However, in this case I need the data registerd in the slave. which
is again not possible....
Martin
Article: 106455Hi, Just to learn VHDL, I cannot understand a problem with the example stopwatch VHDL coming with Xilinx webpack 8.2. In the source window, Inst_dcm1 and XCOUNTER have a red question mark even though I can see there are "dcm1.vhd" and "tenths.vhd" and their module files in the folder. How to attach the respective files to the design? The following is from the readme txt file. * DCM1 -A single DCM clocking module created with Xilinx Architecture Wizard. * DECODE -HDL-based macro. This macro converts a binary input to a one-hot output. * TENTHS -A Coregen 10-bit, one-hot encoded counter. BTW, in which manual talks about the topic? Thank you in advance.Article: 106456
I want to add that the above post is when I try to simulate the behavior function. There are DCM1.xaw and tenths.sco files when I change to Synthesis/Implementation selection. This is a tutorial example. It should have the file for the behavior simulation purpose, right? fl wrote: > Hi, > Just to learn VHDL, I cannot understand a problem with the example > stopwatch VHDL coming with Xilinx webpack 8.2. In the source window, > Inst_dcm1 and XCOUNTER have a red question mark even though I can see > there are "dcm1.vhd" and "tenths.vhd" and their module files in the > folder. How to attach the respective files to the design? The following > is from the readme txt file. > > > * DCM1 -A single DCM clocking module created with Xilinx Architecture > Wizard. > * DECODE -HDL-based macro. This macro converts a binary input to a > one-hot output. > * TENTHS -A Coregen 10-bit, one-hot encoded counter. > > > BTW, in which manual talks about the topic? > > > Thank you in advance.Article: 106457
rickman wrote: > > How do you get a CPLD to reliably oscillate with an RC? > If you can afford 2 more CPLD pins, Peter described it for an FPGA, but should work for CPLD: http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sTechX_ID=pa_six_easy&iLanguageID=1&iCountryID=1 I'm curious: 1) how well does that circuit scale up in frequency, 2) what your frequency needs are? As described, using 470K resistors, the power for that 3 pin RC oscillator looks miniscule. Add a little more gating, you can even shut it off, and re-start time doesn't look much more than half a clock period.Article: 106458
> Martin Schoeberl wrote: >> What helps is to know in advance (one or two cycles) when the result >> will be available. That's the trick with the SimpCon interface. > > That approach is common internally in real cores, but adds a lot of complication while it's an open question how many Avalon > application could benefit from it. It's not that complicated to handle. Even one cycle in advance is nice to know. However, it's just an additional information. You still can ignore it. >> There is not a single ack or waitrequest signal, but a counter that >> will say how many cycles it will take to provide the result. In this >> case I can restart the pipeline earlier. > > AFAIR, Avalon _does_ support slaves with fixed number of latency cycles, but an SDRAM controller by nature won't be fixed cycles. Exactly in this case the counter approach helps. >> Another point is, in my opinion, the wrong role who has to hold data >> for more than one cycle. This is true for several busses (e.g. also >> Wishbone). For these busses the master has to hold address and write >> data till the slave is ready. This is a result from the backplane >> bus thinking. In an SoC the slave can easily register those signals >> when needed longer and the master can continue. > > When happens then when you issue another request to a slave which hasn't finished processing the first? Any queue will be finite > and eventually you'd have to deal with stalling anyway. Any issue is that there are generally many more slaves than masters so it > makes sense to move the complication to the master. I disagree ;-) How hard is it for a slave to hold the read data more than one cycle? Until the next read data is requested and available? That comes almost for free. It's a single register, trivial logic. Ok, is a little overhead for an on-chip peripheral. However, you need usually a MUX in the peripheral for select the IO registers (now using register with a different meaning). Making this MUX registered is almost for free. And you win for the master. Let's say it unformal: Give the master more freedom to move, you usually have less masters than slaves in a system. Therfore, the master(s) will be the bottleneck. > ... >> Wishbone and Avalon specify just a single cycle data valid. > > Again, simplify the slave (and the interconnect) and burden the master. I argue the other way round - now it becomes almost political ;-) > Avalon is IMO the best balance between complexity, performance and features in all the (few) interconnect I've seen yet (I haven't > seen SimpCon yet). In particular I found Wishbone severely lacking for my needs. Avalon is proprietary though, so I roll my own > portable implementation inspired by Avalon with just the features I needed: > - all reads are pipelined with variable latency (accept of request is distinct from delivery of data, thus inherently supporting > multiple outstanding requests) > - multi master support > - burst support (actually not implemented yet, but not that hard) Ok, as you roll your own (like I do) perhaps we can agree on one interface. In that case - two using the same interface - it's almost a standard... > It's nearly as trivial as Wishbone, though offers much higher performance. Latency is entirely up to the slave which can deliver > data as soon as the cycle after the request was posted. (Though, arriving at this simplicity took a few false starts). The same in SimpCon. MartinArticle: 106459
"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> wrote in message news:44de421a$0$12126$3b214f66@tunews.univie.ac.at... >> Not really, it is just simpler to say that I'm not going to go anywhere >> near code that can potentially change any of the outputs if wait request >> is active. As an example, take a look at your code below where you've >> had to sprinkle the 'if av_waitrequest = '0' throughout the code to make >> sure you don't change states at the 'wrong' time (i.e. when >> av_waitrequest is active). Where problems can come up is when you miss >> one of those 'if av_waitrequest = '0' statements. Depending on just >> where exactly you missed putting it in is is where it can be a rather >> subtle problem to debug. > > Agree on the save side, but... > >> >> Now consider if you had simply put the 'if av_waitrequest = '0' statement >> around your entire case statement (with it understood that outside that > > I cannot do this. This case statement is combinatoric. It would introduce > a latch for next_state. The reason to split up the state machine in > a combinatoric next state logic and the clocked part is to react > 'one cycle earlier' with state machine output registers depending > on next_state. You can code this also with a single case in a clock > process. However, than you have to code your output registers on the > transitions (in the if part), which gets a little bit more confusing. Well, there is always great debate between the one process and two process folks about this but whether one thinks that one process or two process is 'more' confusing or not is usually a function of the designer themself. The code will synthesize to the same darn thing. The truth is that either method can be written as clearly and understandably if one tries to. One thing that can definitely be said though is that one process code will be shorter in terms of lines of code. In any case, using my template then by inspection pretty much anyone can guarantee that Avalon won't be violated (in terms of not allowing address or control to change while waitrequest is active). The way you've coded it you're simply replicating the same check on waitrequest in a somewhat confusing manner (i.e. when waitrequest is active and the master is being told to 'wait', you're actively going about changing from one state to the next. To me that is a bit counterintuitive, you've been told to wait. On top of that there is also a state where transitions are made independent of wait request. Hopefully you're never reaching this state when read or write are active or it will cause a failure for not heeding the wait request. Not saying that it can't be made to work just that the code can be simplified quite a bit and made clearer by not writing it this way in the first place. You might try re-writing the process as a synchronous clocked process and see for yourself which is clearer. On top of that using my template you've got the assurance that it will be fully Avalon compliant, with your approach it's not at all obvious if that is the case or not under all operational conditions. > >>> >>> What about this version (sc_* signals are my internal master signals) >>> >>> that case is the next state logic and combinatorial: > > the process containing this case statement is: > > process(state, sc_rd, sc_wr, av_waitrequest) > > begin > > next_state <= state; > >>> >>> case state is >>> >>> when idl => >>> if sc_rd='1' then >>> if av_waitrequest='0' then >>> next_state <= rd; >>> else >>> next_state <= rdw; >>> end if; >>> elsif sc_wr='1' then >>> if av_waitrequest='0' then >>> next_state <= wr; >>> else >>> next_state <= wrw; >>> end if; >>> end if; >>> >>> when rdw => >>> if av_waitrequest='0' then >>> next_state <= rd; >>> end if; -- Oops! Since this is a combinatorial process, then where is the 'else' term on the above 'if' statement? Looks like it will cause a latch. Score one for the one process folks ;) >>> >> >>> when rd => >>> next_state <= idl; >> --- Are you sure you always want to go to idl? This would probably cause >> an error if the avalon outputs were active in this state. > > No problem as next_state goes to rd only when av_waitrequest is '0'. > Perhaps 'rd' is a missleading state name. The input data is registered > when next_state is 'rd'. So state is 'rd' when the input data is > registered. > Might cosider putting an assert that the Avalon read and write signals are not set in the 'rd' state. From a code maintenance perspective, say that somewhere down the road someone wanted to modify the code somewhat and use state 'rd' and didn't 'know' that read and write had better not be set when entering this state. You could add this as a comment, but better to add it as an assert since that is active design code and is a much better flag for design intent. >> >> Whether it works or not for you would take more analysis, I'll just say >> that > > For a complete picture you can look at the whole thing at: > http://www.opencores.org/cvsweb.cgi/~checkout~/jop/vhdl/scio/sc2avalon.vhd > > >>>> You might try looking at incorporating the above mentioned template and >>>> avoid the Avalon violation. What I've also found in debugging other's >>>> code >>> >>> Then I get an additional cycle latency. That's what I want to avoid. >> >> Not on the Avalon bus, maybe for getting stuff into the template but even >> that is a handshake. I've even used Avalon within components to transfer > > Ok, than not at the Avalon bus directly but as you sayed 'getting stuff > into the template'. That's the same for me (in my case). > > If my master has a (internal) read request and I have to forward it > to Avalon in a clocked process (as you do with your template) > I will loose one cycle. Ok in the interface and not in the bus. > Still a lost cycle ;-) > Not always a lost cycle. It would be more properly considered a pipeline stage. A pipelined design adds latency but does not by itself impact performance. In fact, the reason one would use pipelining is to improve clock cycle performance. If you're thinking only about interfacing to an SRAM it would seem that added latency would result in decreased performance (and you'd be right) but in many other situations the latency is rather unimportant. Avalon allows for master and slave components to have latency (in addition to wait states) so that the master is not hung up waiting on a device that has latency (think about a SDRAM/DDR controller, there you have relatively long latency to get at the 'first' hunk of data when accessing a new memory page but one can queue up the commands and run at the exact same rate as the Avalon bus). >> data between rather complicated processes just because it is a clean data >> transfer interface and still have no problem transferring data on every >> clock cycle when it is available. I'm not familiar enough with your >> code, but I suspect that it can be done in your case as well. > > You can do it when your template 'controls' the master logic but not > the other way round. > Not sure what you mean by 'not the other way around'. This template is only for the master side control logic. >>> And then it goes on with slaves with fixed wait states. Why? >>> If do not provide a waitrequest in a slave that needs wait >>> states you can get into troubles when you specify it wrong >>> at component genration. >> >> No, PTF files let you state that there are a fixed number of wait states >> and not have an explicit waitrequest on the slave. > > I meant when you assume n wait states in your VHDL code, but > did a mistake in the PTF file and specified less wait states. > This erro cannot happen when you generate the waitrequest within > your VHDL code. > That's why I never use the PTF file to define the number of wait states. In addition to a fixed number (or time) you can say that it is user controlled which means that the slave device has a 'waitrequest' output. Then it is up to the VHDL to set waitrequest appropriately and if I need to insert or remove a clock cycle of wait states I only change the VHDL for the slave, nothing in the PTF file changes. >>> >>> Or does the Avalon switch fabric, when registered, take this >>> information into account for the waitrequest of the master? >> >> It does. > > That's a reason to go with fix wait states! > A reason for everyone to have fixed wait states?? I think not. That severly limits the types of things you can interface with the bus. Consider a system where you have say a NIOS processor inside an FPGA and it talks over a PCI bus as a bus master to some external component and there are other masters potentially competing for that PCI bus. The Avalon component inside the FPGA that provides the NIOS access to peripherals on the PCI bus would have no idea about how many wait states would be required to complete a particular PCI bus transaction. You almost never want to have a fixed number of wait states but want to simply have the Avalon slave provide a wait request output and tell Avalon that by specifying that in the PTF file. > Or a bus specification that counts down the number of > wait states ;-) > See above and tell me how long to count down. You'd have to figure out a worst case number of wait states for the component, but then you'd be stuck with that even if the component got the data early. Talk about wasting clock cycles. > BTW: Did you take a look into the SimpCon idea? > > Dreaming a little bit: Would be cool to write an > open-source system generator (like SOPC builder) for > it. Including your suggestion of an open and documented > specification file format. > >> >>> Could be for the SRAM component. Should look into the >>> generated VHDL code (or in a simulation)... >>> >> I'd suggest looking at the system.ptf file for your design. > > It's still in ns, which makes sense. > > Martin > >>> Again, one more cycle latency ;-) >> Again, nope not if done correctly. > > I think we finally agreed, did we? > Well if you consider you making a statement and me saying 'nope' to be agreeing then yes we agree ;) I don't see it so much as disagreeing as it is discussing different design approaches and the tradeoffs that one can make. I think your original complaint about the master having to wait until the slave completed the operation is strictly because of the way you chose to implement the interface to the SRAM. On the plus side, you wrote very little code (PTF file stuff, but no VHDL it sounds on the SRAM interface side). On the minus side, I think there might be a latent design error in the timing and your master is stuck having to wait. If done differently the master wouldn't have to wait (except for consecutive reads/writes to the SRAM). KJArticle: 106460
> Well, there is always great debate between the one process and two process folks about this but whether one thinks that one > process or two process is It's just a matter of style. I change it from case to case. We don't need to start a flame on it ;-) > you're simply replicating the same check on waitrequest in a somewhat confusing manner (i.e. when waitrequest is active and the > master is being Again what is confusing depends on style. > On top of that using my template you've got the assurance that it will be fully Avalon compliant, with your approach it's not at > all obvious if that is the case or not under all operational conditions. > >>>> that case is the next state logic and combinatorial: >> >> the process containing this case statement is: >> >> process(state, sc_rd, sc_wr, av_waitrequest) >> >> begin >> >> next_state <= state; .... >> >>>> >>>> when rdw => >>>> if av_waitrequest='0' then >>>> next_state <= rd; >>>> end if; > > -- Oops! Since this is a combinatorial process, then where is the 'else' term on the above 'if' statement? Looks like it will > cause a latch. Score one for the one process folks ;) No, you did not catch me on this one ;-) See above the default assignment: next_state <= state Rule 1 for combinatorial processes: Assign defaults at the beginning to avoid latches. > Might cosider putting an assert that the Avalon read and write signals are not set in the 'rd' state. From a code maintenance > perspective, say that somewhere down the road someone wanted to modify the code somewhat and use state 'rd' and didn't 'know' that > read and write had better not be set when entering this state. You could add this as a comment, but better to add it as an assert > since that is active design code and is a much better flag for design intent. Good idea. Actually I'm using to less asserts in my code. One can improve VHDL coding every day ;-) BTW: I now like records. Synthesizer can handle them and it saves a lot of coding. >> If my master has a (internal) read request and I have to forward it >> to Avalon in a clocked process (as you do with your template) >> I will loose one cycle. Ok in the interface and not in the bus. >> Still a lost cycle ;-) >> > Not always a lost cycle. It would be more properly considered a pipeline stage. A pipelined design adds latency but does not by > itself impact performance. In fact, the reason one would use pipelining is to improve clock cycle performance. If you're > thinking only about interfacing to an ok, ok. Most of the time I'm talking about the read request and a master that needs the result. Therfore I try to avoid latency as much as possible (of course without loosing fmax). >> You can do it when your template 'controls' the master logic but not >> the other way round. >> > Not sure what you mean by 'not the other way around'. This template is only for the master side control logic. Yes, but your trigger of the trasnaction 'within' your Avalon master template. However, for me the Avalon interface is just an interface. It has to react on the request from the CPU. And the CPU requests the transaction from 'outside' of the template/interface. >> I meant when you assume n wait states in your VHDL code, but >> did a mistake in the PTF file and specified less wait states. >> This erro cannot happen when you generate the waitrequest within >> your VHDL code. >> > That's why I never use the PTF file to define the number of wait states. In addition to a fixed number (or time) you can say that > it is user controlled which means that the slave device has a 'waitrequest' output. Then it is up to the VHDL to set waitrequest > appropriately and if I need to insert or remove a clock cycle of wait states I only change the VHDL for the slave, nothing in the > PTF file changes. ... > You almost never want to have a fixed number of wait states but want to simply have the Avalon slave provide a wait request output > and tell Avalon that by specifying that in the PTF file. Completely agree. When not writing and reading too many posts I'm working on that version of the SRAM interface. It was just a quick start as shown in the Quartus manual. >> Or a bus specification that counts down the number of >> wait states ;-) >> > See above and tell me how long to count down. You'd have to figure out a worst case number of wait states for the component, but > then you'd be stuck with that even if the component got the data early. Talk about wasting clock cycles. No, counter was a little bit misleading name. From the spec. it's allowed to jump down more than one increment. E.g. from 2 to 0. Or a very simple slave without pipelining can just say 33330. Than it's like a simple ready signal. That's also the way I translate Avalon to SimpCon :-( >>>> Again, one more cycle latency ;-) >>> Again, nope not if done correctly. >> >> I think we finally agreed, did we? >> > Well if you consider you making a statement and me saying 'nope' to be agreeing then yes we agree ;) ok, than the discussion is on-going ;-) MartinArticle: 106461
JustJohn wrote: > rickman wrote: > >>How do you get a CPLD to reliably oscillate with an RC? >> > > > If you can afford 2 more CPLD pins, Peter described it for an FPGA, but > should work for CPLD: > > http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sTechX_ID=pa_six_easy&iLanguageID=1&iCountryID=1 > > I'm curious: > 1) how well does that circuit scale up in frequency, > 2) what your frequency needs are? > > As described, using 470K resistors, the power for that 3 pin RC > oscillator looks miniscule. RC Osc power is not just resistor power; a significant amount is the linear-region Icc from the pin buffers that are not square wave driven. > Add a little more gating, you can even shut it off, and re-start time > doesn't look much more than half a clock period. Restart time is instant, but you do need to watch the start(idle) values as the first half cycle time can differ from the others, as the circuit changes from rest state, to the ping-pong oscillation cycles. With 3 terminal Osc's, you should also design the Pinout/PCB, so the 'linear' node is adajcent to the positive acting pin(cap), and not the negative acting pin. eg a good pinout is : GND RC Cap+ Res- -jgArticle: 106462
> >> You almost never want to have a fixed number of wait states but want to simply have the Avalon slave provide a wait request >> output and tell Avalon that by specifying that in the PTF file. > > Completely agree. When not writing and reading too many posts > I'm working on that version of the SRAM interface. It was just > a quick start as shown in the Quartus manual. BTW (to KJ): Do you have this type of Avalon slave for an SRAM? Would save some time and errors for me ;-) MartinArticle: 106463
"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> wrote in message news:44df8e1b$0$12642$3b214f66@tunews.univie.ac.at... >> The above is again making me think that we're talking about interfacing >> to an async SRAM. If that's the case, then from your description it >> sounds like Avalon address/read/write basically become the corresponding >> signals on the SRAM. If that's the case, then how are you guaranteeing >> that the address is stable at the SRAM prior to write being asserted and >> after it has been de-asserted. The way the Avalon address and write >> signals work they will both be transitioning some Tco after the rising >> edge of the clock. There is absolutely no guarantee of any timing >> relationship between address and write on the Avalon side, so if those >> are brought out unmodified to the SRAM you have no guarantee there >> either....but for an async SRAM you absolutely have to have that. If >> address and write are nominally transitioning at the 'same' time then you >> won't get reliable operation (or if you build enough of these they will >> 'erratically' fail) because you can't guarantee that you've met the >> timing requirements of the SRAM. > > As I set setup time to 0ns, you're right. There is a little issue (depends > on the tco of the different pins) when wrn goes low before the address > is stable. That's against the SRAM timing spec. (minimum wrn low after > address is 0ns). However, I 'assume' that this does not matter. Setting > Setup_Time to something >0ns will add one additional cycle. That timing does matter, so 'as-is' you do have a timing issue that needs fixing. You also need to insure that at the trailing edge of the SRAM write that the address remains stable. Otherwise it's possible for the SRAM to respond to a write to an address that you had not intended. > > To avoid this little issue and the additional cycle I do usually (with > my SimpCon SRAM controller) clock the nwr with the inverted clock to > shift it after address setup. But now what about the trailing edge or write? The address could start changing and the write signal will still be active. > >> Actually I was referring to what I had described as not being that much >> work. I agree that what you've done doesn't take much work but I also >> don't think that your 'sram_tristate_slave' component will work reliably >> if used to interface with an external asynchronous SRAM. It probably >> will work if you're interfacing it to a synchronous SRAM if you also then >> bring out the Avalon clock as the SRAM clock. > >> design a component that would allow the master to continue on while the >> SRAM operation is still in progress. The only time the master would then >> need to be stalled is if it performed a subsequent access to the SRAM >> while the previous one was still in progress. > > Not for the read (in my case) as I'm waiting for the read data in the > processor. In some cases I can hide the latency by execution of additional > code. However, in this case I need the data registerd in the slave. which > is again not possible.... It is if you write some code for your component and use the 'readdatavalid' Avalon signal it will work. Once you have the address and command safely stored within the component wait request can be set to 0. This can even be happening on a read even if you haven't completed the read (i.e. you don't have the data yet). For example, let's say it takes 10 Avalon clock cycles to complete the read and provide the data. Assuming that the SRAM is currently idle, then when that read comes in from Avalon you do not need to assert wait request at all. Since wait request is not asserted then the master device is free to go off and start up another transaction with any device (i.e. it has not been stalled). Now, 10 Avalon clock cycles later the slave finally get the data in from the SRAM, shoves it out the 'readdata' output and asserts 'readdatavalid'. This signal goes back to the master and now it actually has the data that it was looking for. During those 10 clock cycles while it was waiting it could very well have been off initiating 10 other write cycles to anything else. Unfortunately if a second read is started (even if it not to the SRAM, even if it is to a device that has 0 wait state reads) that read will be greeted by a wait request because Avalon needs to insure that read data is supplied back in the order in which the master requested it. In order to do this it will actually block the second read from even reaching the other slave until the first one (to the SRAM that takes 10 clock cycles) completes. If the second read happens to occur to the same device (in this case the SRAM) such delays won't happen since each component must also supply readdata in the order in which it was requested. Sounds confusing but it isn't, the bottom line is that reads don't necessarily cause the master device to stall. To see all of this clearly, try putting together an SOPC system with a master device and a SDRAM or DDR SDRAM controller out of the MegaCore library. Then watch the interaction between the master and slave side read/write/waitrequest/readdatavalid signals. It'll give you a real good feel for how this Avalon interface can really perform. KJArticle: 106464
"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> wrote in message news:44df9c2e$0$12126$3b214f66@tunews.univie.ac.at... >> Well, there is always great debate between the one process and two >> process folks about this but whether one thinks that one process or two >> process is > > It's just a matter of style. I change it from case to case. > We don't need to start a flame on it ;-) Good ;) > >> -- Oops! Since this is a combinatorial process, then where is the 'else' >> term on the above 'if' statement? Looks like it will cause a latch. >> Score one for the one process folks ;) > > No, you did not catch me on this one ;-) See above the default > assignment: next_state <= state > > Rule 1 for combinatorial processes: Assign defaults at the beginning > to avoid latches. You're right, erase the 'score one...'. Us one process folks don't like writing unneeded code to do those default assignments to avoid something that can't happen because we're in a clocked process.....OK, just couldn't resist. > >>> You can do it when your template 'controls' the master logic but not >>> the other way round. >>> >> Not sure what you mean by 'not the other way around'. This template is >> only for the master side control logic. > > Yes, but your trigger of the trasnaction 'within' your Avalon master > template. However, for me the Avalon interface is just an > interface. It has to react on the request from the CPU. And > the CPU requests the transaction from 'outside' of the > template/interface. > OK, lost again I think. Now it sounds like the CPU even though embedded within the FPGA doesn't have a native Avalon interface and you're talking about a bridge to get you from the CPU interface over to Avalon. Such a bridge though would typically not be terribly application specific but instead is tailored to the signals on the CPU and Avalon. Just like you can make a bridge between Wishbone and Avalon. If the CPU design is your homebrew though a simpler approach is to simply make it have an Avalon compatible interface. When you get to writing that code is where my template would be placed. KJArticle: 106465
"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> wrote in message news:44dfa33e$0$8024$3b214f66@tunews.univie.ac.at... > > >>> You almost never want to have a fixed number of wait states but want to >>> simply have the Avalon slave provide a wait request output and tell >>> Avalon that by specifying that in the PTF file. >> >> Completely agree. When not writing and reading too many posts >> I'm working on that version of the SRAM interface. It was just >> a quick start as shown in the Quartus manual. > > BTW (to KJ): Do you have this type of Avalon slave > for an SRAM? Would save some time and errors for me ;-) > No, over the past several years my use of async SRAMs has gone to 0 even though I used to use them quite heavily. They've been replaced by internal FPGA memory in the Stratix, Stratix II, Cyclone II parts. Any external memory has tended to need to be much larger than async SRAM could affordably provide so DDR has been used. I'm assuming that you've checked and that Altera didn't toss one in as a MegaCore? Too bad. Oh well, I'll stop posting and let you get back to work. KJArticle: 106466
>> To avoid this little issue and the additional cycle I do usually (with >> my SimpCon SRAM controller) clock the nwr with the inverted clock to >> shift it after address setup. > But now what about the trailing edge or write? The address could start changing and the write signal will still be active. The nwe on the negative clock is set to '1' before address change. That's the reason for using the negative clock - get nwr '1' again without an additional cycle. >> Not for the read (in my case) as I'm waiting for the read data in the >> processor. In some cases I can hide the latency by execution of additional >> code. However, in this case I need the data registerd in the slave. which >> is again not possible.... > > It is if you write some code for your component and use the 'readdatavalid' Avalon signal it will work. Once you have the address > and command safely Still not for my case. The slave data is valid only the single cycle when readdatavaild is set. And that one is controled by the slave. I cannot force the slave to hold the read data for the master valid for several cycles. > assert wait request at all. Since wait request is not asserted then the master device is free to go off and start up another > transaction with any device (i.e. it has not been stalled). My master, a processor, cannot issue just any other transaction when a read is issued. I need a.) low latency on read and b.) pipelined read for an efficient cache fill. That's it. No write transaction during an outstanding read. > Unfortunately if a second read is started (even if it not to the SRAM, even if it is to a device that has 0 wait state reads) that > read will be greeted by a wait request because Avalon needs to insure that read data is supplied back in the order in which the > master requested it. In order to do this it Yes, for a more flexible system we would need out-of-order completion. However, this is a completely different story. MartinArticle: 106467
can't resist to answer ;-) >>>> You can do it when your template 'controls' the master logic but not >>>> the other way round. >>>> >>> Not sure what you mean by 'not the other way around'. This template is only for the master side control logic. >> >> Yes, but your trigger of the trasnaction 'within' your Avalon master >> template. However, for me the Avalon interface is just an >> interface. It has to react on the request from the CPU. And >> the CPU requests the transaction from 'outside' of the >> template/interface. >> > OK, lost again I think. Now it sounds like the CPU even though embedded within the FPGA doesn't have a native Avalon interface > and you're talking about a bridge to get you from the CPU interface over to Avalon. Such a bridge though would typically not be > terribly application specific but instead is tailored to the signals on the CPU and Avalon. Just like you can make a bridge > between Wishbone and Avalon. If the CPU design is your homebrew though a simpler approach is to simply make it have an Avalon > compatible interface. When you get to writing that code is where my template would be placed. It is a general case - not about my homebrew CPU: You have a component that (deeply inside not knowing it is connected to Avalon) triggers a read request. With your template this trigger gets registered when waitrequest is '0'. And this registering of the read request adds one cycle latency. Another point: If the waitrequest condition gets deeply embedded in the component it would BTW: for my CPU design - as Avalon is Altera specific I would never make Avalon the native interface. JOP runns quite well on Xilinx devices ;-) MartinArticle: 106468
Gerhard Hoffmann wrote: > I get this error if I do not import the vram.xco file into the > project explicitely by hand. Even though the core generator asks for > the project and should know what is needed. I think earlier versions > than ISE 8.1.? worked without that, but I'm not sure. (I use virtex4, > Ise8.1.current_sp) Thanks! I discovered that using "Insert New Source" and generating the core within the project did actually associate the .xco file with the instance and I *finally* got the project to build, after much frustration. However, during the process coregen asked me for a directory which it subsequently ignored, instead placing everything in the project root directory. I used to swear at Quartus, but now I have a new-found appreciation for it! And whoever decided that the ISE files should be binary... just give me *two* minutes alone with them... >:/ Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 106469
Jim Granville wrote: > rickman wrote: > > How do you get a CPLD to reliably oscillate with an RC? > > Choose one with Schmitt pin options (also important if you want to try > i2c, where the slow edges will mess with non-schmitt CPLDs ). > > That's Atmel's ATF1502BE (32MC), or CoolrunnerII devices. > > You can make 1 pin, 2 pin, or 3 pin Oscillators - the more pins, > the better the precision, and less it depends on the thresholds. > > The numbers I gave are for ATF1502BE. The ATF15xx and Coolrunner II are no gos because of the dual voltages required. Also the ATF parts only come in the relatively huge TQFP44 packages which are four times larger than the csBGA of the Coolrunner parts. I can make a schmitt trigger easily enough with a couple of resistors and an output pin. How about some details on the RC oscillator? I have not seen a 3 pin oscillator before.Article: 106470
In article <1hokk9jzcb6p7$.vjzrwiavdst8$.dlg@40tude.net>, Frank Buss <fb@frank-buss.de> wrote: > David M. Palmer wrote: > > > Alternatively, has anybody put together a complete opencores project > > for this board with the Wishbone bus, a processor, RAM, Ethernet, and > > other things that they could share? There are lots of nice little > > pieces in OpenCores, but I don't see good documentation and examples > > for putting it all together. > > I'm working on this. RS232 sender/receiver and DS2432 one-wire ROM id > reader is finished: > > http://www.frank-buss.de/vhdl/spartan3e.html > > The next big thing will be ethernet and DDR SDRAM support. > > I'm very new to FPGA and VHDL programming, so any comments would be > appreciated, especially if the Wishbone interface is implemented correctly, > because I plan to use this interface for my other components, too. Thank you. The code works, but is it Wishbone? (This is not a rhetorical question, I don't know which of the signals are required and which optional.) The Wishbone appnote http://www.opencores.org/projects.cgi/web/wishbone/appnote_01.pdf says the following are the signals. I have marked them with Y or N depending on whether your entity rs232_sender (for definiteness) has them: 1) Common signals: Y CLK_I Y RST_I N TAG_I/O 2) Data signals Y DAT_I/O 3) Bus Cycle signals Y ACK_I/O N ADR_I/O N CYC_I/O N ERR_I/O N SEL_I/O N RTY_I/O Y STB_I/O N WE_I/O In contrast, the 10/100 Ethernet from OpenCores has all the signals except TAG and RTY. I don't know if that is because they are required in order to be Wishbone, or merely required for that particular core. There are many other questions that I could figure out if I had an example of a complete system. For example, if you have many different registers in a core that you are addressing with the ADR lines, are you supposed ot decode all 32 address lines, or should there be a bus controller that recognizes the high-order address bits and controls STB and WE accordingly? Is that generated by Wishbone Builder? -- David M. Palmer dmpalmer@email.com (formerly @clark.net, @ematic.com)Article: 106471
rickman wrote: > Jim Granville wrote: > >>rickman wrote: >> >>>How do you get a CPLD to reliably oscillate with an RC? >> >>Choose one with Schmitt pin options (also important if you want to try >>i2c, where the slow edges will mess with non-schmitt CPLDs ). >> >>That's Atmel's ATF1502BE (32MC), or CoolrunnerII devices. >> >>You can make 1 pin, 2 pin, or 3 pin Oscillators - the more pins, >>the better the precision, and less it depends on the thresholds. >> >>The numbers I gave are for ATF1502BE. > > > The ATF15xx and Coolrunner II are no gos because of the dual voltages > required. What we need is a CPLD like the Freescale RS08, or the SiLabs C8051F41x - that works from 1.8V to 5.5V, and draws 1uA static Icc :) [ ATF1502BE draws 2.3uA, but needs two rails.... ] > Also the ATF parts only come in the relatively huge TQFP44 > packages which are four times larger than the csBGA of the Coolrunner > parts. Yes, I have already mentioned to Atmel that TQFP44 is large in today's designs.... > I can make a schmitt trigger easily enough with a couple of > resistors and an output pin. > > How about some details on the RC oscillator? I have not seen a 3 pin > oscillator before. One Pin : Bidirectional pin, Open Collector, Res Pullup, Swings between Schmitt VthP and VthN - Tolerance is that of Hyst Band. Duty cycle is narrow. Hard to gate, as CAP is never 0V. Can VCO modulate. Two Pin A : Bidirectional pins ( see 4046 ) Open Collector, Res Pullups, Swings from GND to VthP, Nominally 50% duty cycle. Gates very well Can VCO modulate. Two Pin B : One IP, one OP, Classic HC14 Osc, single Rfb, and Cap, Swings VthP to VthN, Duty cycle is nominally 50%, Poor VCO modulation. Three Pin: One IP and 2 OPs. (See 4060, 4541 et al) Positive feedback to a CAP, negative feedback via resistor, with optional overshoot resistor from CAP to IP pin. Needs layout to have +ve FB next to RC IP pin. Has nominal immunity to pin thresholds, and some PSRR, poor VCO modulation. Gives lowest Icc, as the signal spends least time in high current IP regions. Simplest form, is a non-inverter, followed by inverter (order matters). Can have latches added, to 'de-fur' and can be gated with a little care. See the other link in this thread http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sTechX_ID=pa_six_easy&iLanguageID=1&iCountryID=1 This is a 3 termal RC osc, with a SR latch. -jgArticle: 106472
Hi all, On 2006-08-10 00:32:52 -0700, "Antti" <Antti.Lukats@xilant.com> said: > [lots of useful stuff snipped in the interest of brevity] > > As of multiply access to SDRAM it may be easier to add your peripherals > not to the PLB/OPB bus but to the XCL ports of the multichannel SDRAM > controller. So the high speed access is streamed directly to SDRAM > controller. So, this is probably a stupid question (it's probably in plain view, now that I'm bitching about their site [grin]), but do you have a pointer to the documentation about this SDRAM controller, and how you interface to it (I found XAPP912 :-) ? Or to any of the 'make-your-own-PLB/OPB-device' examples (I found XAPP264 as well, but I was figuring there may be a bit more somewhere, a spec, for example :-) Xilinx sure make it hard to find stuff on their website... I only found the XAPPs above using google... You'd have thought there'd be something directly under http://www.xilinx.com/edk/ ... Thanks in advance :-)Article: 106473
I can only afford a short reply, but ... Martin Schoeberl wrote: >>> Another point is, in my opinion, the wrong role who has to hold data >>> for more than one cycle. This is true for several busses (e.g. also >>> Wishbone). For these busses the master has to hold address and write >>> data till the slave is ready. This is a result from the backplane >>> bus thinking. In an SoC the slave can easily register those signals >>> when needed longer and the master can continue. >> When happens then when you issue another request to a slave which hasn't finished processing the first? Any queue will be finite >> and eventually you'd have to deal with stalling anyway. Any issue is that there are generally many more slaves than masters so it >> makes sense to move the complication to the master. > > I disagree ;-) > How hard is it for a slave to hold the read data more than one cycle? > Until the next read data is requested and available? That comes almost > for free. It's a single register, trivial logic. Ok, is a little overhead > for an on-chip peripheral. However, you need usually a MUX in the > peripheral for select the IO registers (now using register with a different > meaning). Making this MUX registered is almost for free. Focusing on the overhead for one slave supporting one outstanding command is missing the point. Non-trivial slaves can support multiple simultaneous outstanding requests (say N), so they would need at least a queue N deep. Not a problem. Now, I have multiple slaves and multiple masters on the interconnect. Each master must be able to have at least M outstanding requests. Any one slave can only accept one request pr cycle so the interconnect (the arbitration) needs buffer the requests in lots of FIFOs and _they_ add significant latency, logic, and complication (pick two). I actually love decoupled interfaces like these (and they are not a new invention) as it removes the handshaking from the critical paths, but as a general purpose interconnect fabric it just doesn't scale. I'll need to study SimpCon more to understand what you mean by it's support for multiple outstanding requests. Just to clarify, I'm talking about completely independent requests, not bursts. Different masters may issue multiple of these (up to some limit) while previously issued requests are still not complete. I do insist the requests complete in the order they were issued, mostly to simplify things (such as the arbitration). Really just a subset of Avalon. TommyArticle: 106474
Simon Gornall schrieb: > Hi all, > > On 2006-08-10 00:32:52 -0700, "Antti" <Antti.Lukats@xilant.com> said: > > > [lots of useful stuff snipped in the interest of brevity] > > > > As of multiply access to SDRAM it may be easier to add your peripherals > > not to the PLB/OPB bus but to the XCL ports of the multichannel SDRAM > > controller. So the high speed access is streamed directly to SDRAM > > controller. > > So, this is probably a stupid question (it's probably in plain view, > now that I'm bitching about their site [grin]), but do you have a > pointer to the documentation about this SDRAM controller, and how you > interface to it (I found XAPP912 :-) ? Or to any of the > 'make-your-own-PLB/OPB-device' examples (I found XAPP264 as well, but I > was figuring there may be a bit more somewhere, a spec, for example :-) > > Xilinx sure make it hard to find stuff on their website... I only found > the XAPPs above using google... You'd have thought there'd be something > directly under http://www.xilinx.com/edk/ ... > > Thanks in advance :-) the XCL interface is only described in documentation supplied with the EDK, so do not look for any docs on Xilinx website. I think the mch_ edk memory controllers could be used without EDK also with some little wrapper, but such a use is not encouraged Antti
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