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
Brian Boutel wrote: > Michael Wojcik wrote: >> >> If we relax the definition to allow named as well as anonymous >> functions, then someone could argue that get-accessors for properties >> are thunks, and those are quite common in modern languages. > > In functional languages with lazy evaluation (e.g. Haskell) arguments > are passed unevaluated, so an actual argument that is an expression > needs to be parcelled up as a piece of code and an environment in which > is is to be evaluated (i.e the bindings of the free variables in the > code). This amounts to a thunk. Good point. I have a passing familiarity with lazy evaluation, but even with functional programming most of my experience is with eager-evaluating languages like OCaml, so I didn't think of this example. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State UniversityArticle: 146226
On Mar 9, 7:24=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Mar 9, 12:32=A0am, Tricky <trickyh...@gmail.com> wrote:
>
>
>
>
>
> > On 9 Mar, 01:46, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > > Hi,
> > > I have a question about when to generate a latch.
>
> > > In Example_1 and Exmaple_2, I don't think it will generate a latch. I
> > > don't know why.
>
> > > Example_1: process(RESET, CLK)
> > > Begin
> > > =A0 =A0 =A0 =A0 If RESET =3D =911=92 then
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 StateA <=3D S0;
> > > =A0 =A0 =A0 =A0 Elsif CLK=92event =3D =911=92 and CLK =3D =911=92 the=
n
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If SINI =3D =911=92 then
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 StateA <=3D S0;
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Elsif E2 =3D =911=92 then
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 null; =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 -- missing a signal assignment statement
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 -- I suppose it will not generate a latch, why?
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Elsif StateA =3D S1 then
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 StateA <=3D S3;
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Else
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 StateA <=3D StateA_NS=
;
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 End if;
> > > =A0 =A0 =A0 =A0 End if;
> > > End process;
>
> > > Example_2: process(=85)
> > > Begin
> > > =A0 =A0 =A0 =A0 Case StateA is
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ...; =A0 =A0 =A0 =A0 =A0 =A0-- no sig=
nal assignement statements are missing
> > > =A0 =A0 =A0 =A0 End case;
> > > End process;
>
> > > Weng
>
> > In my mind, it generated a register with enable and async reset.
> > Latches are only created when you dont have a clock in a process and
> > you forget to assign something between process iterations.
>
> Example_1: process(RESET, CLK)
> Begin
> =A0 =A0If RESET =3D =911=92 then
> =A0 =A0 =A0 StateA <=3D S0;
> =A0 =A0Elsif CLK=92event =3D =911=92 and CLK =3D =911=92 then
> =A0 =A0 =A0 If SINI =3D =911=92 then
> =A0 =A0 =A0 =A0 =A0StateA <=3D S0;
> =A0 =A0 =A0 Elsif E2 =3D =911=92 then
> =A0 =A0 =A0 =A0 =A0null; =A0 =A0-- missing a signal assignment statement
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- I suppose it will not generate a l=
atch, why?
> =A0 =A0 =A0 Elsif StateA =3D S1 then
> =A0 =A0 =A0 =A0 =A0StateA <=3D S3;
> =A0 =A0 =A0 Elsif C1 /=3D '1' then
> =A0 =A0 =A0 =A0 =A0StateA <=3D StateA_NS;
> =A0 =A0-- else =A0 =A0 =A0 =A0 -- missing a signal assignment statement
> =A0 =A0-- =A0 =A0null; =A0 =A0 -- I suppose it will not generate a latch,=
why?
> =A0 =A0 =A0 End if;
> =A0 =A0End if;
> End process;
>
> Example_2: process(=85)
> Begin
> =A0 =A0Case StateA is
> =A0 =A0 =A0 ...; =A0 =A0 =A0 =A0 =A0 =A0-- no signal assignement statemen=
ts are missing
> =A0 =A0End case;
> End process;
>
> Weng- Hide quoted text -
>
> - Show quoted text -
It isn't clear what you are looking for or trying learn with this code
snippets. In both case these are the classical register coding
styles.
1) The process has two signals, RESET and CLK, in the sensitivity list
2) There is only one signal, StateA, assignment
3) The RESET is coded as an active high level asynchronous reset
function
Note: S0 should be a fixed static value or this will cause
problems
4) The CLK is coded as a rising edge clock and generates the register
element.
Note: Everything within this ELSIF statement is evaluated only on
the rising edge
I would strongly encourage you to change the RESET function from
asynchronous to synchronous.
Ed McGettigan
--
Xilinx Inc.
Article: 146227Muzaffer Kal wrote: > On Fri, 5 Mar 2010 09:07:31 -0800 (PST), Quadibloc <jsavard@ecn.ab.ca> > wrote: >> On Feb 26, 4:56 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote: >> >>> No, he's saying that C doesn't really implement an array type, the >>> var[offset] syntax is just syntactic sugar for *(var + offset) which is why >>> things like 3[x] work the same as x[3] in C. >> Um, no. >> >> x = y + 3 ; >> >> in a C program will _not_ store in x the value of y plus the contents >> of memory location 3. No one claimed it would. But in C, 3[x] == x[3], provided x is a pointer type pointing to an array with at least four elements, just as Steve claimed. > Of course not, given that there is dereference operator anywhwere. On > the other hand > > x = y + *((int*)3); > > would do what you want. No, it wouldn't, since casting an integer to a pointer type causes undefined behavior. It might work (for some value of "work") in some implementations, but it's not valid C. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State UniversityArticle: 146228
Ahem A Rivet's Shot wrote: > > No but x = *(y + 3) will store in x the contents of the memory > location at 3 ... times the size in bytes[1] of the base type of y, which must be an object pointer type ... > + the value of y just as x = y[3] will and x = 3[y] will, > which is what I stated. [1] "bytes" as defined by the C Standard, ie the size of a char object, which may or may not be an octet. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State UniversityArticle: 146229
On Mar 9, 10:15=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Mar 9, 7:24=A0am, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > > > > On Mar 9, 12:32=A0am, Tricky <trickyh...@gmail.com> wrote: > > > > On 9 Mar, 01:46, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > > Hi, > > > > I have a question about when to generate a latch. > > > > > In Example_1 and Exmaple_2, I don't think it will generate a latch.= I > > > > don't know why. > > > > > Example_1: process(RESET, CLK) > > > > Begin > > > > =A0 =A0 =A0 =A0 If RESET =3D =911=92 then > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 StateA <=3D S0; > > > > =A0 =A0 =A0 =A0 Elsif CLK=92event =3D =911=92 and CLK =3D =911=92 t= hen > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If SINI =3D =911=92 then > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 StateA <=3D S0; > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Elsif E2 =3D =911=92 then > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 null; =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 -- missing a signal assignment statement > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- I suppose it will not generate a latch, why= ? > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Elsif StateA =3D S1 then > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 StateA <=3D S3; > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Else > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 StateA <=3D StateA_= NS; > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 End if; > > > > =A0 =A0 =A0 =A0 End if; > > > > End process; > > > > > Example_2: process(=85) > > > > Begin > > > > =A0 =A0 =A0 =A0 Case StateA is > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ...; =A0 =A0 =A0 =A0 =A0 =A0-- no s= ignal assignement statements are missing > > > > =A0 =A0 =A0 =A0 End case; > > > > End process; > > > > > Weng > > > > In my mind, it generated a register with enable and async reset. > > > Latches are only created when you dont have a clock in a process and > > > you forget to assign something between process iterations. > > > Example_1: process(RESET, CLK) > > Begin > > =A0 =A0If RESET =3D =911=92 then > > =A0 =A0 =A0 StateA <=3D S0; > > =A0 =A0Elsif CLK=92event =3D =911=92 and CLK =3D =911=92 then > > =A0 =A0 =A0 If SINI =3D =911=92 then > > =A0 =A0 =A0 =A0 =A0StateA <=3D S0; > > =A0 =A0 =A0 Elsif E2 =3D =911=92 then > > =A0 =A0 =A0 =A0 =A0null; =A0 =A0-- missing a signal assignment statemen= t > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- I suppose it will not generate a= latch, why? > > =A0 =A0 =A0 Elsif StateA =3D S1 then > > =A0 =A0 =A0 =A0 =A0StateA <=3D S3; > > =A0 =A0 =A0 Elsif C1 /=3D '1' then > > =A0 =A0 =A0 =A0 =A0StateA <=3D StateA_NS; > > =A0 =A0-- else =A0 =A0 =A0 =A0 -- missing a signal assignment statement > > =A0 =A0-- =A0 =A0null; =A0 =A0 -- I suppose it will not generate a latc= h, why? > > =A0 =A0 =A0 End if; > > =A0 =A0End if; > > End process; > > > Example_2: process(=85) > > Begin > > =A0 =A0Case StateA is > > =A0 =A0 =A0 ...; =A0 =A0 =A0 =A0 =A0 =A0-- no signal assignement statem= ents are missing > > =A0 =A0End case; > > End process; > > > Weng- Hide quoted text - > > > - Show quoted text - > > It isn't clear what you are looking for or trying learn with this code > snippets. =A0In both case these are the classical register coding > styles. > > 1) The process has two signals, RESET and CLK, in the sensitivity list > 2) There is only one signal, StateA, assignment > 3) The RESET is coded as an active high level asynchronous reset > function > =A0 =A0 =A0Note: S0 should be a fixed static value or this will cause > problems > 4) The CLK is coded as a rising edge clock and generates the register > element. > =A0 =A0 =A0Note: Everything within this ELSIF statement is evaluated only= on > the rising edge > > I would strongly encourage you to change the RESET function from > asynchronous to synchronous. > > Ed McGettigan > -- > Xilinx Inc. Ed, Thank you. WengArticle: 146230
On 3/2/2010 8:15 PM, Jonathan Bromley wrote: > progressive; they are fuelled by discontinuous > changes (the discovery and exploitation of > GMR-effect in disk drives, for example). You > don't immediately see a huge stepwise change > because of these innovations; there's no point > in creating something that's 10 times as good as > the competition, when something 1.5 times as good > will make you rich. So it appears to the casual > or ill-informed observer that things just go on > getting better without innovation, when in truth > it is innovation (and the pull of consumer demand) > that drives it all. > Hi Jonathan, A bit OT, and maybe just hype, but I saw this:- http://news.bbc.co.uk/1/hi/sci/tech/8556656.stm and thought of what you said! Cheers, Syms.Article: 146231
Quadibloc wrote: > > Yes: the array name always refers to the pointer, No, not "always", as has been pointed out more than once in this thread. There are specific contexts where an identifier of array type decays to a pointer to its first element. There are others where it does not, such as when it is the operand of the sizeof operator. This is all spelled out quite clearly in the C standard, and in various other references, some of which were cited upthread. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State UniversityArticle: 146232
Peter Flass wrote: > Michael Wojcik wrote: >> Peter Flass wrote: >>> Hey! C's finally caught up to PL/I. Only took them 50 years, and then >>> of course all the features are just tacked-on in true C fashion, instead >>> of thought-through. >> >> Well, that's rather insulting to the members of WG14, who spent a >> decade designing those features. Fortunately, they published the >> Rationale showing that, in fact, they were thought through.[1] And a >> great deal of documentation describing the process is available in the >> archives.[2] >> >> If you'd care to show why you think otherwise, perhaps there would be >> some grounds for debate. > > "The flexible array must be last"? Doing otherwise would break existing code. WG14's remit is to maintain upward compatibility. > "sizeof applied to the structure ignores the array but counts any > padding before it"? I have no idea what you're quoting there. That phrase doesn't seem to be present in my copy of the standard. > C is a collection of ad-hoc ideas. WG14 may have put a great deal of > thought into how to extend it without breaking the existing mosh, but > that's my point, it's still a mosh. If that was your point, then I have to say it was rather ill-expressed. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State UniversityArticle: 146233
Greg Menke wrote: > Peter Flass <Peter_Flass@Yahoo.com> writes: > >> C is a collection of ad-hoc ideas. WG14 may have put a great deal of >> thought into how to extend it without breaking the existing mosh, but >> that's my point, it's still a mosh. > > iostream formatting operators, because we really need more operator > overloading and no enhancements are too bizarre in service of making > everything, (for particular values of everything), specialized? How fortunate, then, that C does not have them. > Oh but wait, you can compile, install and dig your way through Boost so > as to avoid the fun & games of vanilla iostream. Not in C, you can't. > Thank goodness printf and friends are still around. Indeed, since a great number of C programs use them, and the committee is explicitly charged with maintaining upward compatibility from the first standard. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State UniversityArticle: 146234
Greg Menke wrote: > > C++ does make for a nice "type-safe linking" C compiler. Except that it's not a C implementation, and so is not a C compiler at all. C and C++ are different languages. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State UniversityArticle: 146235
On Mar 9, 4:37=A0am, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > Are you saying that Emacs understands VHDL well enough to build a test > > bench for you? =A0Will it also build a component declaration or > > instantiation automatically? =A0These three things could be automated, > > but I have never taken the time to do it. =A0Making it part of the > > editor makes perfect sense. > > The problem with emacs is you need three knuckles in each finger to > drive it. Remap the caps-lock key to CTRL and you're back to only two knuckles :) -aArticle: 146236
On Mar 8, 4:38=A0pm, rickman <gnu...@gmail.com> wrote: > On Mar 8, 4:40=A0pm, Andy Peters <goo...@latke.net> wrote: > > > > > On Mar 8, 1:32=A0pm, rickman <gnu...@gmail.com> wrote: > > > > On Mar 8, 6:53=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrot= e: > > > > > rickman <gnu...@gmail.com> writes: > > > > > I find the GUI will save me a lot of typing when instantiating > > > > > modules. =A0I use the "generate test bench" feature to build a fi= le > > > > > with the meat and potatoes in it and I copy that to the higher le= vel > > > > > module. > > > > > Ahh, I use VHDL-mode in Emacs for that, which is why I haven't miss= ed > > > > it :) > > > > Are you saying that Emacs understands VHDL well enough to build a tes= t > > > bench for you? > > > It will create a skeleton for you. > > > >=A0Will it also build a component declaration or > > > instantiation automatically? =A0These three things could be automated= , > > > but I have never taken the time to do it. =A0Making it part of the > > > editor makes perfect sense. > > > The skeleton has a nice header, an instance of the DUT, signal > > declarations for all DUT I/O and a simple clock generator. Of course > > you have to create your own stimulus and add instantiations of other > > models as necessary. > > Ok, that's what I get from the Aldec or Lattice ispLever tools. =A0I'll > have to look at EMACs sometime soon. =A0Can it be used to do pretty > print formatting on VHDL files? Yep, it beautifies buffers beautifully. The comprehensive auto-complete feature is the best reason to use emacs and its vhdl-mode. Type pr then <tab> and blam, it inserts a process template, which you can customize with clock name, reset name and type (async/sync) and polarity, and it'll ask for a process label too. Really, I don't know how anyone does any VHDL coding without it. -aArticle: 146237
I've got a problem with my DDR2 (MT47H32M16) on my Spartan3AN board. I use MIG 2.3 controler. The burst lenght is 4. When I'm writing the data like x"A1A1B2B2" or x"01010101" everything works. I'm reading the data after data_valid is set and writing to internal registers. Then I'm sending it to RS232. Problem is when I want write data with zeros... like x"A100B2B2" or x"01010001". Then data which I'm reading are wrong. For x"A100B2B2" A1 I can read but else data are wrong:/ I'm little confused why it happens..Article: 146238
On Mar 8, 4:10=A0pm, "Pete Fraser" <pfra...@covad.net> wrote: > Thankyou everybody for your help so far. > > I seem to be confused by the waveform viewer now. > My typical debug cycle in Modelsim XE uses wave.do. > I will load the sim, run wave.do to bring up the waveforms > I'm interested in, then run the sim. > If the waveforms point to mistakes I've made, I'll often > want to add a few more waveforms, save the updated > wave.do file, then re-start the sim using the new wave.do. > > I can't work out how to do the equivalent in Active-HDL. > My modesim wave.do seems to work in Aldec, but I can't > see how to save it when I've added waveforms. > I can't even work out how to add waveforms reliably; > sometimes dragging signals from the structure pane to an > existing waveform viewer opens a new viewer window. > I'm also not sure which viewer I'm using (advanced or standard), > or how I control that. Sometimes the title bar says > "untitled.awc", and sometimes "untitled.asdb". > > Help, I haven't felt this clueless in a long time. I had a conversation with Aldec support yesterday about this very topic. And I agree -- it's very confusing. There are two things involved with waveform display: a) The .asdb is the waveform data database (sorry for the redundancy). This is a compressed binary that holds all transactions on all signals in the design (not just what is displayed). b) The .awc is the "accelerated waveform configuration" file. This is what the GUI needs to display data in the associated .asdb. BUT! The above files are really only so you can save a copy of a simulation run and display it later without re-running the simulation. What you REALLY want is to do is this. The first time you run your simulation (after Initialize Simulation), you create a new waveform window (which will then show the "untitled.awc" in the title bar), and drag all of the signals of interest into that window. To save this list of signals for future simulation runs, from the Waveform window's menu, choose "Waveform -> Save To Macro." This is akin to the ModelSim menu item "Save Format As ..." and it will create a macro file with the extension .do and it will be stored, by default, in the src directory. It will also appear in the current Design in the Workspace. Once you've created the file, for future simulation runs, you can right-click on the macro file name in the Design and choose "Execute" and it will repopulate the waveform display window with your desired signals. What this means is that unless you really need to save the simulation waveforms, you can shitcan both the .asdb and .awc files. All you need is the macro .do file. -aArticle: 146239
On Mar 8, 1:34=A0pm, rickman <gnu...@gmail.com> wrote: > On Mar 8, 7:04=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > > > KJ <kkjenni...@sbcglobal.net> writes: > > > I guess that's a point in its favour (assuming I can't "convert" the > > incomers to Emacs :) > > You can convert me. =A0I just need to know that it is an advantage to > switch. As the old commercial went, "Try it, you'll like it!" -aArticle: 146240
Michael Wojcik <mwojcik@newsguy.com> writes: > Greg Menke wrote: >> >> C++ does make for a nice "type-safe linking" C compiler. > > Except that it's not a C implementation, and so is not a C compiler at > all. > > C and C++ are different languages. Perhaps so, yet it is possible to compile C programs with a C++ and observe some benefits relating to better compile-time and link-time type checking. One can then disassemble the object modules created by C vs C++ compilers and observe the distinct similarity of with respect to the runtime structure. Which is why it "makes for a nice C compiler", not "is a better C compiler". GregmArticle: 146241
On Mar 9, 2:13=A0pm, Andy Peters <goo...@latke.net> wrote: > On Mar 8, 4:10=A0pm, "Pete Fraser" <pfra...@covad.net> wrote: > > > > > Thankyou everybody for your help so far. > > > I seem to be confused by the waveform viewer now. > > My typical debug cycle in Modelsim XE uses wave.do. > > I will load the sim, run wave.do to bring up the waveforms > > I'm interested in, then run the sim. > > If the waveforms point to mistakes I've made, I'll often > > want to add a few more waveforms, save the updated > > wave.do file, then re-start the sim using the new wave.do. > > > I can't work out how to do the equivalent in Active-HDL. > > My modesim wave.do seems to work in Aldec, but I can't > > see how to save it when I've added waveforms. > > I can't even work out how to add waveforms reliably; > > sometimes dragging signals from the structure pane to an > > existing waveform viewer opens a new viewer window. > > I'm also not sure which viewer I'm using (advanced or standard), > > or how I control that. Sometimes the title bar says > > "untitled.awc", and sometimes "untitled.asdb". > > > Help, I haven't felt this clueless in a long time. > > I had a conversation with Aldec support yesterday about this very > topic. > > And I agree -- it's very confusing. > > There are two things involved with waveform display: > > a) The .asdb is the waveform data database (sorry for the redundancy). > This is a compressed binary that holds all transactions on all signals > in the design (not just what is displayed). WHAT???!!! Is this saying that all of the signals are there and I should be able to display a new signal without rerunning the simulation??? I only see .aws and .adf files, no .asdb file. Do I have to turn a switch to get the .asdb file so I can look at what I want after the simulation is complete? > b) The .awc is the "accelerated waveform configuration" file. This is > what the GUI needs to display data in the associated .asdb. > > BUT! The above files are really only so you can save a copy of a > simulation run and display it later without re-running the simulation. Well, yeah, in essence that's what I'd like to do. > What you REALLY want is to do is this. The first time you run your > simulation (after Initialize Simulation), you create a new waveform > window (which will then show the "untitled.awc" in the title bar), and > drag all of the signals of interest into that window. Yes, go on! > To save this list of signals for future simulation runs, from the > Waveform window's menu, choose "Waveform -> Save To Macro." This is > akin to the ModelSim menu item "Save Format As ..." and it will create > a macro file with the extension .do and it will be stored, by default, > in the src directory. It will also appear in the current Design in the > Workspace. Once you've created the file, for future simulation runs, > you can right-click on the macro file name in the Design and choose > "Execute" and it will repopulate the waveform display window with your > desired signals. > > What this means is that unless you really need to save the simulation > waveforms, you can shitcan both the .asdb and .awc files. All you need > is the macro .do file. Ok, but when I'm debugging, I often need to look at intermediate signals to see where the problem is coming from. It would be great to not have to rerun the simulation to do that. There is more than once that I added some signals only to find that the problem took a slightly different curve than the one I expected and I have to add more signals. In the end I may have to run the simulation 10 or more times before I see the problem. Even at 1 minute each, that can waste a lot of time if there is an easy way to avoid it. So how do I get the .asdb and .awc files? RickArticle: 146242
Michael Wojcik <mwojcik@newsguy.com> writes: > Greg Menke wrote: >> Peter Flass <Peter_Flass@Yahoo.com> writes: >> >>> C is a collection of ad-hoc ideas. WG14 may have put a great deal of >>> thought into how to extend it without breaking the existing mosh, but >>> that's my point, it's still a mosh. >> >> iostream formatting operators, because we really need more operator >> overloading and no enhancements are too bizarre in service of making >> everything, (for particular values of everything), specialized? > > How fortunate, then, that C does not have them. You are quoting out of context. The original topic to which I followed up via the above quote was related to the sometimes "undesigned" appearance of C++. The particular quote above suggests C was already a collection of ad-hoc ideas, so that C++ is not a substantial departure from existing practice. >> Oh but wait, you can compile, install and dig your way through Boost so >> as to avoid the fun & games of vanilla iostream. > > Not in C, you can't. See above. > >> Thank goodness printf and friends are still around. > > Indeed, since a great number of C programs use them, and the committee > is explicitly charged with maintaining upward compatibility from the > first standard. See above. GregmArticle: 146243
On Mar 9, 2:04=A0pm, lusch <lukaszschodow...@gmail.com> wrote: > I've got a problem with my DDR2 (MT47H32M16) on my Spartan3AN board. I > use MIG 2.3 controler. The burst lenght is 4. When I'm writing the > data like x"A1A1B2B2" or x"01010101" everything works. I'm reading the > data after data_valid is set and writing to internal registers. Then > I'm sending it to RS232. > > Problem is when I want write data with zeros... like x"A100B2B2" or > x"01010001". Then data which I'm reading are wrong. For x"A100B2B2" A1 > I can read but else data are wrong:/ > > I'm little confused why it happens.. My guess is that it's the RS-232 link dropping your zeroes, not the memory controller. It's standard practice on serial links to treat null characters (x"00") as nothing, and therefore drop them. Make sure the software at the other end of your RS-232 link is set up to receive binary mode rather than ASCII text. Regards, GaborArticle: 146244
On Sat, 06 Mar 2010 18:55:56 -0600, Charles Richmond
<frizzle@tx.rr.com> wrote:
[snip]
>I think there is *not* a single C programmer who has *not* had his
>hand slapped by making the mistake of using "=" when he meant
>"==". Thus the avalanche of replies... :-)
And because of this stupidity in language design being taken as
acceptable, now, there is, in some related languages, the problem of
using == when you needed ===.
Sincerely,
Gene Wirchenko
Article: 146245Could you please move this discussion about C and related programming languages out of comp.arch.fpga. This thread has deviated considerably from the original posters request which was mostly on topic. AndyArticle: 146246
Michael Wojcik wrote: > Peter Flass wrote: >> Michael Wojcik wrote: >>> Peter Flass wrote: >>>> Hey! C's finally caught up to PL/I. Only took them 50 years, and then >>>> of course all the features are just tacked-on in true C fashion, instead >>>> of thought-through. >>> Well, that's rather insulting to the members of WG14, who spent a >>> decade designing those features. Fortunately, they published the >>> Rationale showing that, in fact, they were thought through.[1] And a >>> great deal of documentation describing the process is available in the >>> archives.[2] >>> >>> If you'd care to show why you think otherwise, perhaps there would be >>> some grounds for debate. >> "The flexible array must be last"? > > Doing otherwise would break existing code. WG14's remit is to maintain > upward compatibility. Yes, as I said, they probably did the best they could with what they had to work with. > >> "sizeof applied to the structure ignores the array but counts any >> padding before it"? > > I have no idea what you're quoting there. That phrase doesn't seem to > be present in my copy of the standard. Same reference as above, a bit farther down. [whatever the link I was sent was, it got clipped somewhere] > >> C is a collection of ad-hoc ideas. WG14 may have put a great deal of >> thought into how to extend it without breaking the existing mosh, but >> that's my point, it's still a mosh. > > If that was your point, then I have to say it was rather ill-expressed. > Most of my points are ill-expressed. I do the best I can with what I've got to work with, too.Article: 146247
[Followups restricted to a.f.c.] Greg Menke wrote: > Michael Wojcik <mwojcik@newsguy.com> writes: >> Greg Menke wrote: >>> C++ does make for a nice "type-safe linking" C compiler. >> Except that it's not a C implementation, and so is not a C compiler at >> all. >> >> C and C++ are different languages. > > Perhaps so, yet it is possible to compile C programs with a C++ Only some C programs. And then you are not compiling C programs with a C++ implementation; you are compiling C++ programs that happen to be written in the common subset of C and C++. > and > observe some benefits relating to better compile-time and link-time type > checking. There's nothing to prevent a conforming C implementation from making similar checks, and some do. And any decent implementation, combined with a modicum of discipline, makes this type checking unnecessary, because the implementation's normal diagnostics will catch everything C++-style name mangling would. For better quality assurance, use real tools like Splint. > One can then disassemble the object modules created by C vs > C++ compilers and observe the distinct similarity of with respect to the > runtime structure. Irrelevant. Many language implementations produce similar output. > Which is why it "makes for a nice C compiler", not "is a better C > compiler". I'm well familiar with this argument - I've heard it since circa 1990, if memory serves. I'm not convinced. Write C for C implementations, and C++ for C++ implementations.Article: 146248
[Followups restricted to a.f.c.] Greg Menke wrote: > Michael Wojcik <mwojcik@newsguy.com> writes: > >> Greg Menke wrote: >>> Peter Flass <Peter_Flass@Yahoo.com> writes: >>> >>>> C is a collection of ad-hoc ideas. WG14 may have put a great deal of >>>> thought into how to extend it without breaking the existing mosh, but >>>> that's my point, it's still a mosh. >>> iostream formatting operators, because we really need more operator >>> overloading and no enhancements are too bizarre in service of making >>> everything, (for particular values of everything), specialized? >> How fortunate, then, that C does not have them. > > You are quoting out of context. Nonsense. I quoted all of your message up to that point, and the relevant part of Peter's. > The original topic to which I followed up via the above quote was > related to the sometimes "undesigned" appearance of C++. Peter did not mention C++. My message, to which he was responding, did not mention C++. I don't see a single reference to C++ in any of the ancestor messages, until your own. > The particular > quote above suggests C was already a collection of ad-hoc ideas, so that > C++ is not a substantial departure from existing practice. An odd thing to "suggest" in a conversation about C. Perhaps you should have noted that you had decided to switch to a different topic.Article: 146249
On 9 Mar, 21:59, Gabor <ga...@alacron.com> wrote: > My guess is that it's the RS-232 link dropping your zeroes, not > the memory controller. =A0It's standard practice on serial links > to treat null characters (x"00") as nothing, and therefore drop > them. =A0Make sure the software at the other end of your RS-232 > link is set up to receive binary mode rather than ASCII text. > > Regards, > Gabor I receive data in serial terminal and I set hexadecimal rather than ASCII so I see exactly byte to byte what I receive. Thanks for replay. Regards
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