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
KJ wrote: > 5. There was also a post either here or in comp.lang.vhdl in the past couple > months that talked about how using the generally listed template can result > in gated clocks getting synthesized when you have some signals that you want > reset, and other signals that you don't. Being in the same process and all, > the original poster found that gated clocks were being synthesized in order > to implement this logic. The correct form of the template (that rarely gets > used by anyone posting to either this group or the vhdl group) is of the > form > process(clk, reset) > begin > if rising_edge(clk) then > s1 <= Something; > s2 <= Something else; > end if; > if (reset = '1') then > s1 <= '0'; > -- s2 does not need to be reset, > end if; > end process; > > Again, the scenario here is that you have > - More than one signal being assigned in this process > - At least one of those signals is not supposed to change as a result of > reset (either this is by intent, or by unintentionally forgetting to put the > reset equation) > > Depending on the synthesis tool, this could result in a gated clock getting > generated as the clock to signal 's2' in the above example. > > KJ KJ, I may be the previous poster you are speaking of... The standard template with "if reset then... elsif rising_edge(clk) then ..." will not cause a gated clock, but rather a clock enabled register, disabled during reset, for those signals not reset in the reset clause. This is also independent of whether reset is coded as a synchronous or an asynchronous input (because of the elsif). The template you used above would allow the normal clocked statements to execute, and then override those signals that are reset, leaving the unreset ones to retain their normal clocked behavior, thus avoiding the need to disable them during reset. Other comments on this thread: If one disables all retiming and other sequential optimizations, then there is definite merit in a descriptive style that explicitly describes combinatorial behavior separately from registered behavior (i.e combinatorial processes or concurrent statements separate from clocked processes). But once retiming, etc. are enabled, all bets are off. In those cases, I believe one is better off focusing on the behavioral (temporal and logical) description and getting it right, and not paying so much attention to specific gates and registers which will not exist in the final result anyway. Since I enable retiming by default, I use single, clocked processes by default as well. One aspect that has not been touched upon is data scoping. One convenient aspect of using variables is that their scope limits their visibility to within the same process. The comment about "related" functions being described in the same process is important in this aspect. There is no need for unrelated functions to have visibility to unrelated signals. Within "one big process" for the whole architecture, scoping can be implemented with blocks, functions, or procedures declared within the process to create islands of related functionality, with limited visibility. I generally prefer to separate unrelated functions to separate processes, but all my processes are clocked. State variables are one such scoping application. I generally don't want any process but the state machine process itself to have any idea of what states I am using, and what they mean (the concept of "information hiding" comes to mind). If I need something external to happen when the state machine is in a certain state, I do it from within the state machine process, either by handling it directly (e.g. adding one to a count), or "exporting" a signal to indicate when it should happen. The same effect can be accomplished with local signal declarations inside a block statement that contains the combinatorial next state process, the output process (if applicable), and the state register process. AndyArticle: 107451
I wrote down a similar question about some skinny rectangles on the perimeter of a SX35. These seem to connect to the connecting wires and have the funny names OMUX, DOUBLE, and HUNIHEX. Any idea about what these are? If the editor does not show us the reality of the physical spaces in the silicon as Austin has suggested that's fine with me. I can speculate on how some features might be too small to show graphically. However, where can one find out about the real sizes of the fabric? Curious minds will want to know if they are planning future ASIC designs or might want to suggest to Xilinx some future designs. Brad Smallridge aivision dot com "Andreas Ehliar" <ehliar@lysator.liu.se> wrote in message news:ecv54t$6jr$1@news.lysator.liu.se... > If I look in the FPGA editor there seems to be one element > in the CLB of a Virtex-4 that is odd as compared to previous > FPGA generations that I have looked at in the FPGA editor. > > The CLB looks something like this in ASCII art: > > +-------------+ > | | +--+ > | | | | > | | | | +-----+ > | | | | |SLICE| > | | | | | | > | | | | +-----+ > | | | | > | | | | +-----+ > | | | | |SLICE| > | | | | | | > | | |??| +-----+ > | Switchbox | |??| > | | | | +-----+ > | | | | |SLICE| > | | | | | | > | | | | +-----+ > | | | | > | | | | +-----+ > | | | | |SLICE| > | | | | | | > | | | | +-----+ > | | | | > | | +--+ > +-------------+ > > > The box with question marks just seems to rearrange the wires so that > they are grouped according to function at the switchbox. > Is that all there is to it? > > /AndreasArticle: 107452
Variables simulate faster because there is no scheduling of a later value update, as with signals (signal values do not actually update until after the assigning process suspends). If the signal has processes that are sensitive to it (i.e. separate combinatorial and registered processes), then there is the process invocation overhead as well. Most modern simulators also merge all processes that are sensitive to the same signal(s), to avoid the duplicate overhead of separate process invocations. Combinatorial processes, because of their widely varying sensitivity lists, foil this optimization. By using only clocked processes with variables, one can write synthesizable RTL that simulates at speeds approaching that of cycle-based code on cycle accurate simulators. Andy Duane Clark wrote: > KJ wrote: > > ... > > The drawback of signals is that take longer simulation time...wasted > > time too. I'm trying to resurrect the test code that I had comparing > > use of variables versus signals but I seem to remember about a 10% hit > > for signals... > > I would be interested in whether anyone has theories on why variables > would simulate faster than signals. And whether this behavior has been > seen on different simulators, or only Modelsim.Article: 107453
Andy wrote:
> I may be the previous poster you are speaking of...
>
> The standard template with "if reset then... elsif rising_edge(clk)
> then ..." will not cause a gated clock, but rather a clock enabled
> register, disabled during reset, for those signals not reset in the
> reset clause. This is also independent of whether reset is coded as a
> synchronous or an asynchronous input (because of the elsif).
Exactly. Synthesis will go through asynchronous contortions
to *prevent* a register from being reset.
This is why I reset all registers the same way
and why I don't touch my process template
between _begin_ and _end_.
> But once retiming, etc. are enabled, all bets are
> off. In those cases, I believe one is better off focusing on the
> behavioral (temporal and logical) description and getting it right, and
> not paying so much attention to specific gates and registers which will
> not exist in the final result anyway.
Well said.
-- Mike Treseler
Article: 107454Brad, Of course, we are not interested in helping anyone design an ASIC, so you are unlikely to get much in the way of support there. As for suggesting what you would like in future FPGAs, we are (of course) always open to suggestions. On the other hand, since what we do we consider proprietary, we are not going to share schematics with you. Austin Brad Smallridge wrote: > I wrote down a similar question about > some skinny rectangles on the perimeter > of a SX35. These seem to connect to > the connecting wires and have the funny > names OMUX, DOUBLE, and HUNIHEX. Any > idea about what these are? > > If the editor does not show us the reality > of the physical spaces in the silicon as > Austin has suggested that's fine with me. > I can speculate on how some features > might be too small to show graphically. > > However, where can one find out about the > real sizes of the fabric? Curious minds > will want to know if they are planning future > ASIC designs or might want to suggest to Xilinx > some future designs. > > Brad Smallridge > aivision > dot com > > "Andreas Ehliar" <ehliar@lysator.liu.se> wrote in message > news:ecv54t$6jr$1@news.lysator.liu.se... >> If I look in the FPGA editor there seems to be one element >> in the CLB of a Virtex-4 that is odd as compared to previous >> FPGA generations that I have looked at in the FPGA editor. >> >> The CLB looks something like this in ASCII art: >> >> +-------------+ >> | | +--+ >> | | | | >> | | | | +-----+ >> | | | | |SLICE| >> | | | | | | >> | | | | +-----+ >> | | | | >> | | | | +-----+ >> | | | | |SLICE| >> | | | | | | >> | | |??| +-----+ >> | Switchbox | |??| >> | | | | +-----+ >> | | | | |SLICE| >> | | | | | | >> | | | | +-----+ >> | | | | >> | | | | +-----+ >> | | | | |SLICE| >> | | | | | | >> | | | | +-----+ >> | | | | >> | | +--+ >> +-------------+ >> >> >> The box with question marks just seems to rearrange the wires so that >> they are grouped according to function at the switchbox. >> Is that all there is to it? >> >> /Andreas > >Article: 107455
"Antti" <Antti.Lukats@xilant.com> wrote: > >in any case - I can not and do not want to belive that Xilinx designed >boards with features knowing not to work (at the time of the board >design). > Lets say Xilinx is a bit too optimistic about their devices every now and then. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 107456
Hello, OMUX, DOUBLE, HUNIHEX, VUNIHEX, etc... are all names given to different types of routing resources. If you highlight the various types, you can get an idea of what kind of routing they provide. Those skinny rectangles around the perimeter are to "clean up" the boundary of the device. The device is an array of regular building blocks. Each building block has programmable logic and routing resources. So what do you do with the routing resources at the perimeter of the array? Clicking on the routing resources where they enter these skinny rectangles will give you the answer. Eric "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message news:12f6dhsjksfnaa3@corp.supernews.com... > > I wrote down a similar question about > some skinny rectangles on the perimeter > of a SX35. These seem to connect to > the connecting wires and have the funny > names OMUX, DOUBLE, and HUNIHEX. Any > idea about what these are?Article: 107457
Has anyone here had any experiance with the Actel Fusion FPGAs? I saw a couple of posts asking this about 6 months ago, but no one had hardware yet. Did they finally start shipping their demo boards? Is this true programable analog, with filtering/amplification/etc, or is it just an analog mux to an ADC? Thanks, MikeArticle: 107458
Antti wrote: > New low cost families other than from Xilinx are known to be coming > this autumn (Cyclone-3, MAX3, LatticeXP2) but there is no advance info > an Spartan-4 yet, is there a hope at all that there will be modern low > cost family from Xilinx too? > > Spartan-3 is 'not for new designs' as there is no price roadmap for it, > Spartan-3E only has small members, eg not replacement for S3 > > so we have vacuum in the place of Spartan-4 ! I see also Actel have announced what they call Igloo - press release claims 5uW static power, but table shows 20uA @ 1.2V static typical power ? - wait, I see FlashFreeze has 4uA in smallest device, seems the press release writer has rather confused his static power, with his flash-freese. Not the first time that's happened, but they should fix that. Smallest device has no ram, and no sleep mode number. ( so this will be their 'loss leader' "$1.50 in volume" device. On their bar comparison, PolarPro seems very poor, and I notice MachXO is missing - could this omission mean it has better numbers ? :) -jgArticle: 107459
Nico, I think you said it pretty well. SATA was also a moving target. The standard had not yet been released when we were working on things. An attempt was made to be capable of testing things once the boards were available. As for the future, I have said that we are not SATA compatible now, and have no IP today, and that is true. I am saying nothing about the future, either immediate, or not so immediate. I am told that if you are serious about SATA, you should contact your Xilinx FAE. Austin Nico Coesel wrote: > "Antti" <Antti.Lukats@xilant.com> wrote: > >> in any case - I can not and do not want to belive that Xilinx designed >> boards with features knowing not to work (at the time of the board >> design). >> > > Lets say Xilinx is a bit too optimistic about their devices every now > and then. >Article: 107460
Eric, But it is still an abstraction of the actual schematic. Austin Eric Crabill wrote: > Hello, > > OMUX, DOUBLE, HUNIHEX, VUNIHEX, etc... are all names given to different > types of routing resources. If you highlight the various types, you can get > an idea of what kind of routing they provide. > > Those skinny rectangles around the perimeter are to "clean up" the boundary > of the device. The device is an array of regular building blocks. Each > building block has programmable logic and routing resources. So what do you > do with the routing resources at the perimeter of the array? Clicking on > the routing resources where they enter these skinny rectangles will give you > the answer. > > Eric > > "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message > news:12f6dhsjksfnaa3@corp.supernews.com... >> I wrote down a similar question about >> some skinny rectangles on the perimeter >> of a SX35. These seem to connect to >> the connecting wires and have the funny >> names OMUX, DOUBLE, and HUNIHEX. Any >> idea about what these are? > >Article: 107461
I got my board some weeks ago, but had no time to play with it yet... Thomas www.entner-electronics.com "MikeD" <mmdst23@gmail.com> schrieb im Newsbeitrag news:1156795063.217881.84720@i42g2000cwa.googlegroups.com... > Has anyone here had any experiance with the Actel Fusion FPGAs? I saw > a couple of posts asking this about 6 months ago, but no one had > hardware yet. Did they finally start shipping their demo boards? > > Is this true programable analog, with filtering/amplification/etc, or > is it just an analog mux to an ADC? > > Thanks, > Mike >Article: 107462
Hi Austin,
Certainly. My answer is from a purely functional ("software view")
standpoint as observable in FPGA Editor.
Eric
"Austin Lesea" <austin@xilinx.com> wrote in message
news:ecvj41$sr914@xco-news.xilinx.com...
> Eric,
>
> But it is still an abstraction of the actual schematic.
>
> Austin
>
> Eric Crabill wrote:
> > Hello,
> >
> > OMUX, DOUBLE, HUNIHEX, VUNIHEX, etc... are all names given to different
> > types of routing resources. If you highlight the various types, you can
get
> > an idea of what kind of routing they provide.
> >
> > Those skinny rectangles around the perimeter are to "clean up" the
boundary
> > of the device. The device is an array of regular building blocks. Each
> > building block has programmable logic and routing resources. So what do
you
> > do with the routing resources at the perimeter of the array? Clicking
on
> > the routing resources where they enter these skinny rectangles will give
you
> > the answer.
> >
> > Eric
> >
> > "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
> > news:12f6dhsjksfnaa3@corp.supernews.com...
> >> I wrote down a similar question about
> >> some skinny rectangles on the perimeter
> >> of a SX35. These seem to connect to
> >> the connecting wires and have the funny
> >> names OMUX, DOUBLE, and HUNIHEX. Any
> >> idea about what these are?
> >
> >
Article: 107463Andy wrote: > KJ wrote: > > 5. There was also a post either here or in comp.lang.vhdl in the past couple > > months that talked about how using the generally listed template can result > > in gated clocks <snip> > KJ, > > I may be the previous poster you are speaking of... > > The standard template with "if reset then... elsif rising_edge(clk) > then ..." will not cause a gated clock, but rather a clock enabled > register, disabled during reset, for those signals not reset in the > reset clause. <snip> No, you weren't the one Andy although you and I did discuss resets on that thread as well. The one I'm referring to is from June 15 in comp.lang.vhdl called "alternate synchronous process template" started by "Jens" (all that just in case the link below doesn't work) http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/77006ae7297b6e86/?hl=en# At the time, nobody seemed to dispute Jen's claim that the gated clock could be created....I dunno, don't use them async resets ;) > > Other comments on this thread: > > If one disables all retiming and other sequential optimizations, then > there is definite merit in a descriptive style that explicitly > describes combinatorial behavior separately from registered behavior > (i.e combinatorial processes or concurrent statements separate from > clocked processes). I'm not sure what merit you see in that. I'm describing the functionality of the entity. If there is some need for what amounts to a combinatorial function of the current state I'll do it with a concurrent statement whereas you and Mike T will do it with a variable. In either case, we would be trying to implement the same function whether optomizations were on or off. > But once retiming, etc. are enabled, all bets are > off. In those cases, I believe one is better off focusing on the > behavioral (temporal and logical) description and getting it right, and > not paying so much attention to specific gates and registers which will > not exist in the final result anyway. The "focusing on the behavioral (temporal and logical) description..." is what I'm focused on as well. I also couldn't care less about "specific gates and registers which will not exist in the final result anyway". I'm just trying to get the function and timing to meet the goal, if it all gets mushed together in the synthesis process that's fine...that's what I pay for the tool to do.... Either that or I'm missing what your point is, I've been known to do that. > One aspect that has not been touched upon is data scoping. One > convenient aspect of using variables is that their scope limits their > visibility to within the same process. The comment about "related" > functions being described in the same process is important in this > aspect. There is no need for unrelated functions to have visibility to > unrelated signals. I'll agree but add that that is somewhat of a 'religious' statement. If taken to the other extreme yes you have a huge mass of only global signals (and I'm not advocating that) but if one breaks the problem down into manageable sized entities you don't (or should I say, I don't) tend to have hundreds of signals in the architecture either. It's a managable size, say from 0 to 2 dozen as a rough guess. > Within "one big process" for the whole architecture, > scoping can be implemented with blocks, functions, or procedures > declared within the process to create islands of related functionality, This wouldn't address the issue I brought up about the use of Modelsim's Dataflow window as a debug aid, but OK....my islands of related functionality are the multiple processes and the concurrent statements. > with limited visibility. I generally prefer to separate unrelated > functions to separate processes, but all my processes are clocked. As do I. > > State variables are one such scoping application. I generally don't > want any process but the state machine process itself to have any idea > of what states I am using, and what they mean (the concept of > "information hiding" comes to mind). I would consider that to be a 'religion' thing. I wouldn't draw the somewhat arbitrary boundary, I consider all of the logic implemented in an entity to be closely enough related that they can at least talk amongst themselves if it is helpful to get the overall function implemented. Not really disagreeing with you, just saying that there is no reason that relates back to the functional spec that would justify this hiding so I wouldn't necessarily break them apart unless the 'process fits on a screen' fuzzy rule starts kicking up. > If I need something external to > happen when the state machine is in a certain state, I do it from > within the state machine process, either by handling it directly (e.g. > adding one to a count), or "exporting" a signal to indicate when it > should happen. And that tends to muddy the waters somewhat for someone following the code since they can't perceive the interaction between the state machine and the outputs all in one fell swoop that they could if it was put together (and it didn't violate the 'process fitting on a screen' fuzzy rule. Good points, I don't necessarily disagree with the idea of local scoping and information hiding as a general guiding principle but it can be taken as dogma too that results in hiding things from those who have a need to know (i.e. those other statements, processes, etc. that are all within the same entity/architecture). If you view all of those statements and processes in an entity as being part of the same 'team' doing their little bit to get the overall function of the entity implemented none is really more important than the other, they all live and die together. By that rather crude sports analogy the idea of 'information hiding' should be taken with some suspicion. And yes, I realize that VHDL has nothing to do with sports just thought I'd toss out an unrelated analogy to break up the day. But which approach one takes is definitely a function of just how 'big' the function is being implemented. One with hundreds of signals would be far worse than multiple processes with local variables all scoped properly. But if you have hundreds of signals I'll bet you have thousands of lines of code all within one architecture and I'll bet would be a good candidate for some refactoring and breaking it down into multiple subentities that could be understood individually instead of only as some large collective. KJArticle: 107464
"Peter Alfke" <alfke@sbcglobal.net> writes: > I almost threw up when I read John Bass explain how he uses a > deliberately dumb-sounding name plus naive questions to light some fire > and create controversial flames. > Really destroys my enthusiasm for this newsgroup. Understandable. Remember though that there are many of us here that really appreciate your contributions. Have a good trip! Will you get some vacationing in before or after the conference? I haven't been to Madrid, but I'd love to go. Best regards, EricArticle: 107465
Hello, I found the solution at Xilinx answer record # 23274 I hope this will be help for other people SivakanthArticle: 107466
I am testing my design on Xilinx ML402 board. I can send data from the PC to the FPGA board through the parallel port using LVTTL pin constrains. Header used is J6 at 3.3V. Problem is reading from the FPGA to the PC thorugh the parallel port. It doesn't seem to read anything, I measured the voltage on the header's lines when it is connected to the parallel port and it is 2.5V. When there is no connection to the PC, the voltage is 3.3V which seems OK. But why I can not read anything on my PC from the parallel port? Thanks, DanArticle: 107467
G=F6ran Bilski wrote:
> David wrote:
> > Hi all,
> >
> > I'm trying to implement a correlator as a coprocessor on the FSL bus.
> > The first thing I've done is generate the FSL example using the create
> > peripheral wizard in EDK 8.1 and hooked it up to the MicroBlaze. When
> > I do a blocking write or read the MB stalls - my understanding is that
> > this will happen if the FSL FIFO is full or empty respectively, but it
> > happens the first time I write to it, so the FIFO should not be full.
> >
> > If I use non-blocking reads and writes and check the error and invalid
> > flags after each one using fsl_isinvalid() and fsl_iserror() - see code
> > below - everything seems normal but the output is always zero. Am I
> > implementing the error checking macros correctly?
> >
> >
> > #define write_into_fsl(val, id) nputfsl(val, id)
> > #define read_from_fsl(val, id) ngetfsl(val, id)
> >
> > #define WRITE_FSL_TEST_0(val) write_into_fsl(val,
> > XPAR_FSL_FSL_TEST_0_INPUT_SLOT_ID)
> > #define READ_FSL_TEST_0(val) read_from_fsl(val,
> > XPAR_FSL_FSL_TEST_0_OUTPUT_SLOT_ID)
> >
> >
> > void fsl_test_app(
> > unsigned int* input_0, /* Array size =3D 2 */
> > unsigned int* output_0 /* Array size =3D 2 */
> > )
> > {
> > int i;
> > Xuint8 is_error =3D 0;
> > Xuint8 is_valid =3D 0;
> >
> > print("Entering fsl_test_app \r\n");
> >
> > //Start writing into the FSL bus
> > for (i=3D0; i<2; i++)
> > {
> >
> > WRITE_FSL_TEST_0(input_0[i]);
> > fsl_iserror(is_error);
> > xil_printf("error post: %d \r\n", is_error);
> > fsl_isinvalid(is_valid);
> > xil_printf("valid post: %d \r\n", is_valid);
> > }
> > print("Finished Write \r\n");
> >
> > is_error =3D 0;
> > is_valid =3D 0;
> >
> > //Start reading from the FSL bus
> > for (i=3D0; i<2; i++)
> > {
> > READ_FSL_TEST_0(output_0[i]);
> > fsl_iserror(is_error);
> > xil_printf("error post: %d \r\n", is_error);
> > fsl_isinvalid(is_valid);
> > xil_printf("valid post: %d \r\n", is_valid);
> > }
> > }
> >
> > I added external ports to the FSL core to check the reset polarity and
> > monitor the state machine - the core is not being held at reset, but
> > always sits in the Idle state. This, coupled with the blocking
> > instruction problems seems to indicate an issue with the FSL FIFO
> > perhaps (I have tried both BRAM and non-BRAM FIFO implementations)?
> > If anyone has any ideas on what might be going wrong your help would be
> > much appreciated...
> >
> >
> > Cheers,
> >
> > David
> >
> Hi,
>
> Can you show the .mhs where you have connected your FSL core with
> Microblaze?
>
> G=F6ran Bilski
Hi G=F6ran,
Thanks for your reply, here are the relevant parts of the .mhs file:
BEGIN microblaze
PARAMETER INSTANCE =3D microblaze_0
PARAMETER HW_VER =3D 4.00.a
PARAMETER C_USE_FPU =3D 0
PARAMETER C_DEBUG_ENABLED =3D 1
PARAMETER C_NUMBER_OF_PC_BRK =3D 2
PARAMETER C_FSL_LINKS =3D 1
BUS_INTERFACE DLMB =3D dlmb
BUS_INTERFACE ILMB =3D ilmb
BUS_INTERFACE DOPB =3D mb_opb
BUS_INTERFACE IOPB =3D mb_opb
BUS_INTERFACE SFSL0 =3D fsl_v20_0
BUS_INTERFACE MFSL0 =3D fsl_v20_1
PORT CLK =3D sys_clk_s
PORT DBG_CAPTURE =3D DBG_CAPTURE_s
PORT DBG_CLK =3D DBG_CLK_s
PORT DBG_REG_EN =3D DBG_REG_EN_s
PORT DBG_TDI =3D DBG_TDI_s
PORT DBG_TDO =3D DBG_TDO_s
PORT DBG_UPDATE =3D DBG_UPDATE_s
END
BEGIN fsl_v20
PARAMETER INSTANCE =3D fsl_v20_0
PARAMETER HW_VER =3D 2.00.a
PARAMETER C_EXT_RESET_HIGH =3D 0
PARAMETER C_IMPL_STYLE =3D 1
END
BEGIN fsl_v20
PARAMETER INSTANCE =3D fsl_v20_1
PARAMETER HW_VER =3D 2.00.a
PARAMETER C_EXT_RESET_HIGH =3D 0
PARAMETER C_IMPL_STYLE =3D 1
END
BEGIN fsl_test
PARAMETER INSTANCE =3D fsl_test_0
PARAMETER HW_VER =3D 1.00.c
BUS_INTERFACE MFSL =3D fsl_v20_0
BUS_INTERFACE SFSL =3D fsl_v20_1
PORT reset_out =3D fsl_test_0_reset_out
PORT state_debug =3D fsl_test_0_state_debug
END
Cheers,
David
Article: 107468Wow, I never even noticed he said "gated clock" in the OP of that other thread. I have never seen that, just the clock-disabled registers (which creates a problem when the reset asynchronously asserts, all mine synchronously deassert anyway). The synthesis tool is not just trying to keep those unreset registers from resetting, it is keeping them from doing anything else while the other registers are reset, which is exactly the way the code simulates, because of the elsif. Avoiding the elsif by using a parallel if statement (whether synchronous or asynchronous) at the end avoids the clock-disables. The main place where I have run into this is when inferring memories from arrays. The array cannot be reset, otherwise you get a slew of registers. But if it is in a process with other registers that do get reset, then that creates a problem, which is solved by putting the reset clause in parallel, at the end. Occasionally, resets cause optimization or routing problems when I'm trying to squeeze the most performance from a design, and I'll remove the reset from those registers as well if it is not needed. My general preference is to reset everything though, and I generally use the traditional form since it will give me a warning if something is not reset. I don't take data scoping to a religious level, but I do keep it in mind, even below the architecture level. When coding state machines and their outputs, I prefer to see everything associated with one state in one place. If it is not there, it does not have visibility of the state anyway, the way I code it. That way if I change my mind about the organization or naming of the states, the effects of such a change are limited to one place and one place only. It is more for maintenance than anything else, to try to limit the extent to which all those signals are interweaved, and impossible to untangle. VHDL makes it relatively easy to see what all the inputs are to a function, but finding all the places where a signal goes is another matter. That's what the text search function is for... As to when to isolate different processes in a separate entity/architecture, that is a touchy-feely type of decision. I usually know it when I see it, but trying to describe a set of rules for it is much more difficult than just doing it. Because my coding styles are generally more compact than those with separate processes for combo and registered logic, I generally get more in an architecture before it gets too big. So a lightweight scoping mechanism is useful to deal with more complexity within a given architecture. Let's just say it helps keep a borderline too-complex description from overflowing into multiple entity/architectures. I like your "what fits on a screen" standard for processes. That seems to work well for me too. That could be extended to functions and procedures too, although mine are not usually anywhere near that long, and they are usually defined within the process anyway. My point about merits of separate combinatorial and clocked processes is that most proponents of that style like the fact that they can easily visualize what is gates and what is registers. I try to encourage them to lift their visual ceilings (and floors, to some extent) and focus on behavior since, especially with retiming and other sequential optimizations, their original description will have little in common with the synthesis output, except for the behavior which is often obscured by the separation of registers from gates in the first place. The same argument applies to using variables for registers and/or combinatorial logic. Thanks for the ideas... Andy KJ wrote: > Andy wrote: > > KJ wrote: > > > 5. There was also a post either here or in comp.lang.vhdl in the past couple > > > months that talked about how using the generally listed template can result > > > in gated clocks > <snip> > > KJ, > > > > I may be the previous poster you are speaking of... > > > > The standard template with "if reset then... elsif rising_edge(clk) > > then ..." will not cause a gated clock, but rather a clock enabled > > register, disabled during reset, for those signals not reset in the > > reset clause. > <snip> > No, you weren't the one Andy although you and I did discuss resets on > that thread as well. The one I'm referring to is from June 15 in > comp.lang.vhdl called "alternate synchronous process template" started > by "Jens" (all that just in case the link below doesn't work) > http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/77006ae7297b6e86/?hl=en# > > At the time, nobody seemed to dispute Jen's claim that the gated clock > could be created....I dunno, don't use them async resets ;) > > > > > Other comments on this thread: > > > > If one disables all retiming and other sequential optimizations, then > > there is definite merit in a descriptive style that explicitly > > describes combinatorial behavior separately from registered behavior > > (i.e combinatorial processes or concurrent statements separate from > > clocked processes). > I'm not sure what merit you see in that. I'm describing the > functionality of the entity. If there is some need for what amounts to > a combinatorial function of the current state I'll do it with a > concurrent statement whereas you and Mike T will do it with a variable. > In either case, we would be trying to implement the same function > whether optomizations were on or off. > > > But once retiming, etc. are enabled, all bets are > > off. In those cases, I believe one is better off focusing on the > > behavioral (temporal and logical) description and getting it right, and > > not paying so much attention to specific gates and registers which will > > not exist in the final result anyway. > The "focusing on the behavioral (temporal and logical) description..." > is what I'm focused on as well. I also couldn't care less about > "specific gates and registers which will > not exist in the final result anyway". I'm just trying to get the > function and timing to meet the goal, if it all gets mushed together in > the synthesis process that's fine...that's what I pay for the tool to > do.... > > Either that or I'm missing what your point is, I've been known to do > that. > > > One aspect that has not been touched upon is data scoping. One > > convenient aspect of using variables is that their scope limits their > > visibility to within the same process. The comment about "related" > > functions being described in the same process is important in this > > aspect. There is no need for unrelated functions to have visibility to > > unrelated signals. > I'll agree but add that that is somewhat of a 'religious' statement. > If taken to the other extreme yes you have a huge mass of only global > signals (and I'm not advocating that) but if one breaks the problem > down into manageable sized entities you don't (or should I say, I > don't) tend to have hundreds of signals in the architecture either. > It's a managable size, say from 0 to 2 dozen as a rough guess. > > > Within "one big process" for the whole architecture, > > scoping can be implemented with blocks, functions, or procedures > > declared within the process to create islands of related functionality, > This wouldn't address the issue I brought up about the use of > Modelsim's Dataflow window as a debug aid, but OK....my islands of > related functionality are the multiple processes and the concurrent > statements. > > > with limited visibility. I generally prefer to separate unrelated > > functions to separate processes, but all my processes are clocked. > As do I. > > > > > State variables are one such scoping application. I generally don't > > want any process but the state machine process itself to have any idea > > of what states I am using, and what they mean (the concept of > > "information hiding" comes to mind). > I would consider that to be a 'religion' thing. I wouldn't draw the > somewhat arbitrary boundary, I consider all of the logic implemented in > an entity to be closely enough related that they can at least talk > amongst themselves if it is helpful to get the overall function > implemented. Not really disagreeing with you, just saying that there > is no reason that relates back to the functional spec that would > justify this hiding so I wouldn't necessarily break them apart unless > the 'process fits on a screen' fuzzy rule starts kicking up. > > > If I need something external to > > happen when the state machine is in a certain state, I do it from > > within the state machine process, either by handling it directly (e.g. > > adding one to a count), or "exporting" a signal to indicate when it > > should happen. > And that tends to muddy the waters somewhat for someone following the > code since they can't perceive the interaction between the state > machine and the outputs all in one fell swoop that they could if it was > put together (and it didn't violate the 'process fitting on a screen' > fuzzy rule. > > Good points, I don't necessarily disagree with the idea of local > scoping and information hiding as a general guiding principle but it > can be taken as dogma too that results in hiding things from those who > have a need to know (i.e. those other statements, processes, etc. that > are all within the same entity/architecture). > > If you view all of those statements and processes in an entity as being > part of the same 'team' doing their little bit to get the overall > function of the entity implemented none is really more important than > the other, they all live and die together. By that rather crude sports > analogy the idea of 'information hiding' should be taken with some > suspicion. And yes, I realize that VHDL has nothing to do with sports > just thought I'd toss out an unrelated analogy to break up the day. > > But which approach one takes is definitely a function of just how 'big' > the function is being implemented. One with hundreds of signals would > be far worse than multiple processes with local variables all scoped > properly. But if you have hundreds of signals I'll bet you have > thousands of lines of code all within one architecture and I'll bet > would be a good candidate for some refactoring and breaking it down > into multiple subentities that could be understood individually instead > of only as some large collective. > > KJArticle: 107469
Hi Austin, Is it the online store that went off in May or June that you are talking about? the same one on the Xilinx portal and straight from Xilinx warehouse (in Singapore for example)? Is it really going to be back online? and with Virtex-4 and 5 for sale? Woh, if that's the truth, then you make my day!!! Please dont forget to put discount prices for relatively big qty too (>24) Cheers Jacques Austin Lesea wrote: > Brian, > > Peter is still tilting at that windmill (the on line store). > > I am cheering him on. > > Perhaps Peter can tell us how the on line store is progressing when he > bets back from Europe. > > AustinArticle: 107470
Austin Lesea wrote: > As for the future, I have said that we are not SATA compatible now, and > have no IP today, and that is true. Then completely update the docs online to be specifically clear. Not hidden 67 pages in, a non-descript area, roughly fine print.Article: 107471
fpga_t...@yahoo.com wrote: > Austin Lesea wrote: > > As for the future, I have said that we are not SATA compatible now, and > > have no IP today, and that is true. > > Then completely update the docs online to be specifically clear. Not > hidden 67 pages in, a non-descript area, roughly fine print. Beter yet, revise to docs to not call it SATA, but rather a Xilinx bit serial development prototype for testing protocols such as SATA.Article: 107472
Dan, Which parallel port signals are you trying to read? On old parallel ports, the data pins can only be outputs from the PC. Cheers, Syms. "EEngineer" <maricic@gmail.com> wrote in message news:1156804493.078190.57560@74g2000cwt.googlegroups.com... > PC, the voltage is 3.3V which seems OK. But why I can not read anything > on my PC from the parallel port? > > Thanks, > Dan >Article: 107473
Hi all, Sun has open SPARC micro architecture document. You may download it here. SPARC Micro-arch doc: http://www.opensparc.net/ http://opensparc-t1.sunsource.net/specs/OpenSPARCT1_Micro_Arch.pdf Is there anyone like to study and learn the idea from it? Best regards, DavyArticle: 107474
you are turning out to be a jewel in the discussion ... thanks :) rickman wrote: > I understand what you are saying, but I think the Ritchey method is > very simple and effective. The range of change in the inductance of > the various via placements is not so large that it swamps out the > inductance of the cap which I would say dominates. In any event, if > you just use a range of cap values to provide multiple SRFs you end up > with a very broad low impedance power plane. This was shown both in > simulation and in measurements. I got the impression from somewhere, that the bga carriers that are direct die attach also have their own power and ground planes, so that an individual chip pwr/gnd couples to those planes, which are then coupled in parallel to the users PCB power planes. It seems that if this is true, and Xilinx provided both some serious bulk capacitance and mixed high speed, that the current profiles thru the parallel vias to the users pcb should be much calmer, and not have a lot of harmonics. The planes would probably be a hacked up mesh at best, but better than 4mil traces. > I can't say a design failed because of low loss caps, but Ritchey had > very clear measurements that showed a strong ESR peak where the caps > resonated with the plane. By using caps with a higher ESR the > resonance was damped out and the impedance "hole" was eliminated. Hmmm ... that explains some experimental data, thanks!! And contrary to this thread, why stacked cap debug configurations sometimes seem to actually work since the 0.1uf and 1uf "bulk caps" stacked over the 0.01uf would have a different ESR's and help damp this by flattening the current profile in both the cap's and via's inductive response. The 0.01uf caps high current recharge path would be the two bulk caps instead of resonating with the pwr/gnd plane, and the 0.1uf would more slowly reduce the current source to the via inductor, tapering off rather than more abruptly running out of charge early, thus smoothing/damping the via inductors resonate current response. Or did I miss something?
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