Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 146225

Article: 146225
Subject: Re: using an FPGA to emulate a vintage computer
From: Michael Wojcik <mwojcik@newsguy.com>
Date: Tue, 09 Mar 2010 13:15:19 -0500
Links: << >>  << T >>  << A >>
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 University

Article: 146226
Subject: Re: Why doesn't this situation generate a latch?
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Tue, 9 Mar 2010 10:15:34 -0800 (PST)
Links: << >>  << T >>  << A >>
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: 146227
Subject: Re: using an FPGA to emulate a vintage computer
From: Michael Wojcik <mwojcik@newsguy.com>
Date: Tue, 09 Mar 2010 13:19:22 -0500
Links: << >>  << T >>  << A >>
Muzaffer 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 University

Article: 146228
Subject: Re: using an FPGA to emulate a vintage computer
From: Michael Wojcik <mwojcik@newsguy.com>
Date: Tue, 09 Mar 2010 13:22:27 -0500
Links: << >>  << T >>  << A >>
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 University

Article: 146229
Subject: Re: Why doesn't this situation generate a latch?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Tue, 9 Mar 2010 10:25:59 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

Weng

Article: 146230
Subject: Re: Tabula. (FPGA start up)
From: Symon <symon_brewer@hotmail.com>
Date: Tue, 09 Mar 2010 18:30:14 +0000
Links: << >>  << T >>  << A >>
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
Subject: Re: using an FPGA to emulate a vintage computer
From: Michael Wojcik <mwojcik@newsguy.com>
Date: Tue, 09 Mar 2010 13:32:02 -0500
Links: << >>  << T >>  << A >>
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 University

Article: 146232
Subject: Re: using an FPGA to emulate a vintage computer
From: Michael Wojcik <mwojcik@newsguy.com>
Date: Tue, 09 Mar 2010 13:40:27 -0500
Links: << >>  << T >>  << A >>
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 University

Article: 146233
Subject: Re: using an FPGA to emulate a vintage computer
From: Michael Wojcik <mwojcik@newsguy.com>
Date: Tue, 09 Mar 2010 13:42:08 -0500
Links: << >>  << T >>  << A >>
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 University

Article: 146234
Subject: Re: using an FPGA to emulate a vintage computer
From: Michael Wojcik <mwojcik@newsguy.com>
Date: Tue, 09 Mar 2010 13:42:55 -0500
Links: << >>  << T >>  << A >>
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 University

Article: 146235
Subject: Re: Modelsim PE vs. Aldec Active-HDL (PE)
From: Andy Peters <google@latke.net>
Date: Tue, 9 Mar 2010 10:54:36 -0800 (PST)
Links: << >>  << T >>  << A >>
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 :)

-a

Article: 146236
Subject: Re: Modelsim PE vs. Aldec Active-HDL (PE)
From: Andy Peters <google@latke.net>
Date: Tue, 9 Mar 2010 10:57:03 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

-a

Article: 146237
Subject: Spartan3AN DDR2 - bad writing zeros
From: lusch <lukaszschodowski@gmail.com>
Date: Tue, 9 Mar 2010 11:04:21 -0800 (PST)
Links: << >>  << T >>  << A >>
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
Subject: Re: Some Active-HDL questions
From: Andy Peters <google@latke.net>
Date: Tue, 9 Mar 2010 11:13:16 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

-a

Article: 146239
Subject: Re: Modelsim PE vs. Aldec Active-HDL (PE)
From: Andy Peters <google@latke.net>
Date: Tue, 9 Mar 2010 11:14:50 -0800 (PST)
Links: << >>  << T >>  << A >>
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!"

-a

Article: 146240
Subject: Re: using an FPGA to emulate a vintage computer
From: Greg Menke <gusenet@comcast.net>
Date: Tue, 09 Mar 2010 15:10:58 -0500
Links: << >>  << T >>  << A >>
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".

Gregm

Article: 146241
Subject: Re: Some Active-HDL questions
From: rickman <gnuarm@gmail.com>
Date: Tue, 9 Mar 2010 12:11:25 -0800 (PST)
Links: << >>  << T >>  << A >>
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?

Rick

Article: 146242
Subject: Re: using an FPGA to emulate a vintage computer
From: Greg Menke <gusenet@comcast.net>
Date: Tue, 09 Mar 2010 15:18:10 -0500
Links: << >>  << T >>  << A >>
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.

Gregm

Article: 146243
Subject: Re: Spartan3AN DDR2 - bad writing zeros
From: Gabor <gabor@alacron.com>
Date: Tue, 9 Mar 2010 12:59:04 -0800 (PST)
Links: << >>  << T >>  << A >>
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,
Gabor

Article: 146244
Subject: Re: using an FPGA to emulate a vintage computer
From: Gene Wirchenko <genew@ocis.net>
Date: Tue, 09 Mar 2010 12:59:59 -0800
Links: << >>  << T >>  << A >>
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: 146245
Subject: Re: using an FPGA to emulate a vintage computer
From: Andy Botterill <andy@plymouth2.demon.co.uk>
Date: Tue, 09 Mar 2010 21:18:45 +0000
Links: << >>  << T >>  << A >>
Could 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. Andy

Article: 146246
Subject: Re: using an FPGA to emulate a vintage computer
From: Peter Flass <Peter_Flass@Yahoo.com>
Date: Tue, 09 Mar 2010 16:56:40 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: using an FPGA to emulate a vintage computer
From: Michael Wojcik <mwojcik@newsguy.com>
Date: Tue, 09 Mar 2010 17:59:25 -0500
Links: << >>  << T >>  << A >>
[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
Subject: Re: using an FPGA to emulate a vintage computer
From: Michael Wojcik <mwojcik@newsguy.com>
Date: Tue, 09 Mar 2010 17:59:44 -0500
Links: << >>  << T >>  << A >>
[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
Subject: Re: Spartan3AN DDR2 - bad writing zeros
From: lusch <lukaszschodowski@gmail.com>
Date: Tue, 9 Mar 2010 15:59:48 -0800 (PST)
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search