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
2017JanFebMarApr2017

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 137050

Article: 137050
Subject: filtering decimation of a signal
From: Jamie Morken <jmorken@shaw.ca>
Date: Sun, 21 Dec 2008 01:33:05 -0800
Links: << >>  << T >>  << A >>
Hi,

I have a 100kHz sampling frequency ADC hooked up to an FPGA (CycloneII) 
and would like to use a FIR filter to lowpass this signal down to about 
50Hz -3dB cutoff frequency.  The Quartus FIR builder attenuates DC when 
I put 100kHz input and 50Hz output in it, is there a better way to do 
this perhaps decimate the input signal or use nested FIR filters?  I 
would like to get an average of this 100kHz sampled data basically with 
about a 5Hz to 50Hz update rate.

cheers,
Jamie

Article: 137051
Subject: Programming Actel A3P with SVF files
From: Antti <Antti.Lukats@googlemail.com>
Date: Sun, 21 Dec 2008 01:37:08 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi

I am trying to use amontec SVF player to program Actel FPGA using the
SVF files generated with Libero 8.5

and getting error on erase already. the SVF seems to be executed
correctly, the ID is checked the execution time is correct, but the
part just doesnt get erased

any hints?

Antti

Article: 137052
Subject: Re: Bit width in CPU cores
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Sun, 21 Dec 2008 05:03:12 -0600
Links: << >>  << T >>  << A >>
In article <46017e00-ae8e-45d7-945f-020dd34b6483@20g2000yqt.googlegroups.com>,
 rickman <gnuarm@gmail.com> writes:
>I am resurrecting a CPU design I created some years back for use in an
>FPGA.  It was highly optimized for minimal resource usage, both logic
>and BRAMs.  One of the things I didn't optimize fully is the usage of
>the full 9 bits of BRAMs in most FPGAs.  When used in byte width or
>larger, they use multiples of 9 bits rather than 8 to provide a parity
>bit.  It seems a waste to ignore these bits.
>
>I have already optimized the instruction set fairly well for a zero-
>operand architecture (dual stack based) using 8 bit instructions.  In
>general, 8 bits is overkill for this sort of machine.  For example,
>various MISC CPUs use 5 bit instructions packed into larger words.
>There is no  need for 256 different instructions, so I used an
>immediate field in the jump and call instructions and still have a
>total of 36 instructions.
>
>Given this as a starting point, an easy way to use this extra bit is
>as a return flag.  There are any number of instructions that if
>followed by a return, could now be combined saving both the time of
>execution and the byte of storage for the return instruction.
...


Dick (Richard E) Sweet did his thesis on this area at Stanford in 1977.
  Empirical Estimates of Program Entropy

That approach was used on the Mesa instruction set at Xeorx.
The ACM will sell you a copy of his thesis (or a paper derived
from it) 168 pages.  There is also a PARC CSL report on the Mesa
work.  The Computer History Museum has a copy.  The library at PARC
may have copies but they have probably pitched them by now.

The goal of that work was to reduce the size of the code.  (It
seems a bit silly with all the bloat out there now, but we
thought it was important back then.  An Alto had 1/2 megabyte
of RAM.)

My memory is that most of the instructions were loads and stores.
I expect that will depend upon your sample set.  How much code
do you have?  Do you have a compiler or are you coding in
assembly?

The Mesa world had a stack and a PC and two pointer registers.
We called them Local and Global.  Local was a pointer to the
stack frame for the current subroutine.  Global was the pointer
to the module's storage.  (static in c)  The Local stack frames
were not actually a stack.  They came from a heap so you could
do co-routines and fancy stuff like that.

Anyway, if you read Dick's thesis or the Mesa report, I'll bet it
will give you some ideas.  I'm pretty sure he had a version of
the compiler that parsed the code and spit out normalized
(un-optomized) intermediate data that he could analyze with
another set of tools.  (aka compress)

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 137053
Subject: Re: filtering decimation of a signal
From: "kadhiem_ayob" <kadhiem_ayob@yahoo.co.uk>
Date: Sun, 21 Dec 2008 07:24:33 -0600
Links: << >>  << T >>  << A >>
Hi,

Sounds you are interested in the time domain mainly. If so you may accept
the sinc envelope of an averaging lowpass filter.
Your cutoff is too low(50/100,000) so even running average filter will
need a long delay line. An integrator may do the job.
use power of 2 taps e.g. 2048 taps: add 2048 samples and get their average
at the end of addition in a feedback adder by truncating 11 bits. You will
need a counter to start-stop-clear the feedback adder. This gives an update
of once every 2048 cycles of 100kHz i.e. about 50Hz.
I don't see how decimation is going to help, what is the bandwidth of your
signal?

kadhiem






Article: 137054
Subject: FPGA for Contoll
From: "RealInfo" <therightinfo@yahoo.com>
Date: Sun, 21 Dec 2008 15:32:38 +0200
Links: << >>  << T >>  << A >>
Hi

Is FPGA a good choice for control applications like contrloling
electric gates , microvaves, industrial nachinery etc , or this niche is 
best done
by regular microcontrollers like 8051 etc ?

Thanks
ec 



Article: 137055
Subject: Re: Programming Actel A3P with SVF files
From: Antti <Antti.Lukats@googlemail.com>
Date: Sun, 21 Dec 2008 05:42:42 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 21, 11:37=A0am, Antti <Antti.Luk...@googlemail.com> wrote:
> Hi
>
> I am trying to use amontec SVF player to program Actel FPGA using the
> SVF files generated with Libero 8.5
>
> and getting error on erase already. the SVF seems to be executed
> correctly, the ID is checked the execution time is correct, but the
> part just doesnt get erased
>
> any hints?
>
> Antti

Hm

after spending 5 hours with UrJTAG compile and test under cygwin
it looks that Amontex SVF player did succeed in both erase/program/
verify

I have not yet tested with FlashPro if the part is correctly
programmed
but all the SVF verify operations are OK now

Antti




Article: 137056
Subject: Re: FPGA for Contoll
From: Lorenz Kolb <lorenz.kolb@uni-ulm.de>
Date: Sun, 21 Dec 2008 15:23:49 +0100
Links: << >>  << T >>  << A >>
RealInfo wrote:
> Hi
> 
> Is FPGA a good choice for control applications like contrloling
> electric gates , microvaves, industrial nachinery etc , or this niche is 
> best done
> by regular microcontrollers like 8051 etc ?

This highly depends on the purpose.

If it's a really cheap consumer product you might want to give a 
microcontroller a go.
If you highly depend on in-field upgradability you might want to give an 
fpga a go. It also depends on the amount of computing power you need. If 
you just want to program some microcontroller into the fpga and run 
c-code on it an fpga might be quite an overkill (though in terms of 
availibility of the parts fpga might be better in some cases (at least 
when thinking about really long term availibility for industrial use).

It is quite easy to build complete controll-paths that a really 
real-time into an FPGA, where it might be quite hard to proof that your 
microcontroller will be able to fulfill critical time constraints.

To sum up: it highly depends on the task, knowledge, time-to-market, 
costs etc.

> 
> Thanks
> ec 
> 
> 

Regards,

Lorenz

Article: 137057
Subject: Why MyHDL?
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Sun, 21 Dec 2008 16:53:34 +0100
Links: << >>  << T >>  << A >>
Hello:

MyHDL is a Python package for using Python as a
Hardware Description Language.

A new release is upcoming, and on this occasion
we have prepared a page about why MyHDL may
be useful to you:

     http://www.myhdl.org/doku.php/why

Regards,

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a hardware description language:
     http://www.myhdl.org



Article: 137058
Subject: Re: FPGA for Contoll
From: "RealInfo" <therightinfo@yahoo.com>
Date: Sun, 21 Dec 2008 18:22:30 +0200
Links: << >>  << T >>  << A >>
Thanks
EC


"Lorenz Kolb" <lorenz.kolb@uni-ulm.de> ??? 
??????:494e5176@news.uni-ulm.de...
> RealInfo wrote:
>> Hi
>>
>> Is FPGA a good choice for control applications like contrloling
>> electric gates , microvaves, industrial nachinery etc , or this niche is 
>> best done
>> by regular microcontrollers like 8051 etc ?
>
> This highly depends on the purpose.
>
> If it's a really cheap consumer product you might want to give a 
> microcontroller a go.
> If you highly depend on in-field upgradability you might want to give an 
> fpga a go. It also depends on the amount of computing power you need. If 
> you just want to program some microcontroller into the fpga and run c-code 
> on it an fpga might be quite an overkill (though in terms of availibility 
> of the parts fpga might be better in some cases (at least when thinking 
> about really long term availibility for industrial use).
>
> It is quite easy to build complete controll-paths that a really real-time 
> into an FPGA, where it might be quite hard to proof that your 
> microcontroller will be able to fulfill critical time constraints.
>
> To sum up: it highly depends on the task, knowledge, time-to-market, costs 
> etc.
>
>>
>> Thanks
>> ec
>
> Regards,
>
> Lorenz 



Article: 137059
Subject: Re: Bit width in CPU cores
From: Jecel <jecel@merlintec.com>
Date: Sun, 21 Dec 2008 08:26:54 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 21, 7:13 am, rickman wrote:
> I meant to crosspost to CLF and I also wanted to ask if anyone has
> looked at similarly making the word size a multiple of 9 rather than 8
> bits.  That not only matches the BRAMs, but also the multipliers.  Is
> there any real advantage to this?  I guess this could make it a bit
> hard to address 8 bit bytes in an 18 bit word.  Or maybe not.
> Opinions?

The Intellasys chips use 18 bit words. In several places, 9 bit
addresses are used. Only whole words are addressed, not bytes.
Instructions are 5 bits wide, but of the four that fit into an 18 bit
words the last only has the top 3 bits (the lower bits are assumed to
always be 0).

-- Jecel

Article: 137060
Subject: Re: Bit width in CPU cores
From: m_l_g3 <m_l_g3@yahoo.com>
Date: Sun, 21 Dec 2008 09:32:17 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 21, 12:13 pm, rickman <gnu...@gmail.com> wrote:
> I meant to crosspost to CLF and I also wanted to ask if anyone has
> looked at similarly making the word size a multiple of 9 rather than 8
> bits.  That not only matches the BRAMs, but also the multipliers.  Is
> there any real advantage to this?  I guess this could make it a bit
> hard to address 8 bit bytes in an 18 bit word.  Or maybe not.
> Opinions?
>

ANS Forth says that address units need not be bytes.
You may have 18-bit AUs, 9-bit AUs, or 6-bit AUs.
(In the latter case you will need a fast division by 3 :).

On a processor that used 16-bit words and ignored the least
significant bit, it was easy to make a software emulation of
byte access (by the way, both big- and little-endian could be
emulated).

As to instructions, do you want to pack commands of the
same size into 18-bit words, or it is ok to have commands
of different sizes?

For example, you can make a frequency study of instruction
usage, and encode more frequently used instructions with
a smaller amount of bits. (Yes, I am a mathematician.)
You can pack up to 4 instructions into a 18-bit word,
provided that only 2 of them are 5-bit.
You will not need to shift more than by one bit:
if the instruction is 4-bit (bits 0-3), the next
instruction starts at bit 4;
if the instruction is 5-bit (bits 0-4), you will
need to shift the word by 1 bit to have the next
instruction at the same bit 4.

Alternatively, you may have three 5-bit instructions and one
3-bit instruction (having some defaults about the two bits
that are not there).

Only 1 memory access per 3 or 4 instructions ;)


Article: 137061
Subject: Re: Bit width in CPU cores
From: rickman <gnuarm@gmail.com>
Date: Sun, 21 Dec 2008 09:33:48 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 21, 11:26 am, Jecel <je...@merlintec.com> wrote:
> On Dec 21, 7:13 am, rickman wrote:
>
> > I meant to crosspost to CLF and I also wanted to ask if anyone has
> > looked at similarly making the word size a multiple of 9 rather than 8
> > bits.  That not only matches the BRAMs, but also the multipliers.  Is
> > there any real advantage to this?  I guess this could make it a bit
> > hard to address 8 bit bytes in an 18 bit word.  Or maybe not.
> > Opinions?
>
> The Intellasys chips use 18 bit words. In several places, 9 bit
> addresses are used. Only whole words are addressed, not bytes.
> Instructions are 5 bits wide, but of the four that fit into an 18 bit
> words the last only has the top 3 bits (the lower bits are assumed to
> always be 0).
>
> -- Jecel

The main thing I am worried about with 18 bit words is byte
addressing.  Bytes could be addressed as 8 bit quantities packed into
an 18 bit word with two bits unused (or used as parity perhaps), or
they could be 9 bits each.  9 bit bytes is unusual, but a "byte" is
not a fixed number of bits.  I have also see machines (old ones
admittedly) with a 36 bit word and 6 bit bytes.  I think the bytes
used for character data was called "field code".  This was a way of
optimizing character data for limited storage.  But I think that is
way too complex for a tiny core CPU.

I like the idea of 9 bit bytes since that matches the instruction
width.  I'm just wondering if it will make trouble when character data
is used in arithmetic.  To use bytes in arithmetic requires the sign
bit to be extended. With 9 bit bytes, the question is whether to
extend the ninth bit or the eighth. Doing one or the other in hardware
could make the other very awkward.  I guess I could just wait until I
have something to write code for and see how it works.  It's not like
the instruction set is cast in stone at any point.  Its also possible
that it's not need to be done in hardware at all.

How does the Intellasys chips use 9 bit addresses?  Are these just
immediate fields within instructions?  I have trouble remembering the
details of the various Forth CPUs, but I want to say the Intellasys
chip is one of Chuck Moore's designs and uses a full word for an
instruction that contains immediate data/address.  But that would be 5
bit instruction and 13 bit immediate.  That doesn't seem to match.
Besides, I want to say that was in the context of a 20 bit instruction
word.  I guess I am mixing different incarnations.

Rick

Article: 137062
Subject: Re: Large BRAM synthesis
From: Gael Paul <gael.paul@gmail.com>
Date: Sun, 21 Dec 2008 10:07:12 -0800 (PST)
Links: << >>  << T >>  << A >>
Ben,

Two factors explain the performance limitations of large memories:
 - logic delay in input muxing (address and controls) and output
muxing (dataout)
 - high-fanout nets

Let's work through these through an example: a 16Mbit single port
memory (80% of a V5 LXT50) organized as 512Kx32. When performance
matters synthesis tools typically decompose memories using "tall and
thin" BRAMs to minimize the logic depth of input/output muxing. In
this case, the decomposition would be an array of 16 x 32 instances of
32Kx1 BRAMs.
Let's look at the logic/fanout implications of this decomposition:
 - datain: each bit has a fanout of 16
 - dataout: each bit goes through a 16-to-1 mux (2 logic levels)
 - addr[14:0]: each bit has a fanout of 512 (every BRAM)
 - addr[18:15]:
    - output side: used as select of the 16-to-1 output muxes, with a
fanout of 32*2 (assuming two logic levels for a 16-to-1 mux using 6-
input LUTs)
    - input side: used to build a 4-to-16 decoder (BRAM select) (1
logic level). Each of the 16 select bits is combined with we (1 logic
level) and has then a fanout of 32
 - we: fanout of 16
 - ce: fanout of 512 (every BRAM) [note: a power-aware decomposition
would actually combine the BRAM select signals with ce, as done with
we. The fanout would then be 16, but with one logic level.)

As suggested by other posters, adding pipeline stages on both sides of
the memory is required to improve performance (through manual or
automatic retiming). It obviously will speed-up the logic delay, but
will have no impact on high-fanout nets without additional work. And,
I woud contend that the limiting factor is actually the 15 address
nets with a 512 fanout each. For these nets, I'd suggest using the
pipeline registers to build a tree of flip-flops. That is done by
replicating the pipeline FFs (manually or through maxfan synthesis
constraints) AND by adding "keep" constraints to prevent the synthesis
or P&R tool to merge the redundant FFs. For a 512 fanout, with 2
pipeline FFs, you would want to have 8 copies of the first FF, and 64
of the second. Each net in this tree would have a fanout of 8. You'd
have to do the same for other high-fanout nets. I'm also guessing that
2 pipeline stages would be needed on the output side. One as output
registers of the BRAMs, one all final outputs to isolate from the rest
of the design.

Now, you're not done yet. With the wonderful netlist described above,
post P&R performance will most likely be disappointing. This comes for
the actual placement of the BRAMs, which will obviously span across
the entire chip. And while you have greatly reduced the fanout of the
high-fanout nets, chances are very low that BRAMs driven by the same
pipeline FF will end-up in the same vicinity. In other words, you'd
have to be incredibly lucky to have your logical partitioning (groups
of 8 BRAMs) matching the physical partitioning. The solution here lies
in manually placing the BRAMs. That can be done with simple
constraints, or with fancy floorplanners.

Finally, all of this is moot if your design cannot tolerate extra
latency in accessing the memory. In the above example, we added 4
pipeline stages. There is no chance the resulting netlist hits 5X the
original frequency, i.e. 500Mhz. However, 200-300Mhz seems achievable.

I hope that helps,

 - gael

Article: 137063
Subject: Re: Bit width in CPU cores
From: Elizabeth D Rather <erather@forth.com>
Date: Sun, 21 Dec 2008 08:48:09 -1000
Links: << >>  << T >>  << A >>
rickman wrote:
...
> How does the Intellasys chips use 9 bit addresses?  Are these just
> immediate fields within instructions?  I have trouble remembering the
> details of the various Forth CPUs, but I want to say the Intellasys
> chip is one of Chuck Moore's designs and uses a full word for an
> instruction that contains immediate data/address.  But that would be 5
> bit instruction and 13 bit immediate.  That doesn't seem to match.
> Besides, I want to say that was in the context of a 20 bit instruction
> word.  I guess I am mixing different incarnations.

Remember, each core has only 64 words of RAM and 64 words of ROM.  From 
the Data Sheet concerning branches:

The size and interpretation of the branch address field is affected by
opcode packing. The field is always right justified within the same
instruction word as the opcode that controls it. The slot number of the
branch opcode will determine the number of high order bits available to
the address field. Each of the branch cases, and its affect upon address
size and effective address calculation, are illustrated in Table 3.4.

Example 1: If the opcode is in Slot 0, there is room for a full nine 
bits of address and a tenth bit to set extended mode.

Example 2: In Slot 1, there is room for eight address bits. Note that 
eight bits will reach all of RAM and ROM, but cannot reach the I/O 
ports. In other words, P8 is always set to 0 when branching from slot 1. 
P9 is not affected by Slot 2 banches.

Example 3: In Slot 2, 3 address bits are available. These three bits are
combined with five bits of the P register to form an 8-bit address. P8 
is set to 0 when branching from Slot 2. Note that the address is in the 
same 8- word page as the value of the P register when the opcode 
executes. P9 is not affected by Slot 2 banches.

--------

Direct addressing uses the 9-bit B register.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

Article: 137064
Subject: Re: Bit width in CPU cores
From: foxchip <fox@ultratechnology.com>
Date: Sun, 21 Dec 2008 11:45:52 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 21, 9:33=A0am, rickman <gnu...@gmail.com> wrote:
> Opinions?

I see two issues; FPGA and Forth.  There is the issue that many
FPGA offer 18-bit wide logic that can easily be used for 18b-bit
wide memory and math.  There is the issue that Forth comes from
a tradition of being word oriented both at the semantic level
and evaluation level.

Chuck has said that Forth is word oriented and that we should
recognize that and take advantage of it.  All his hardware and
software has been word addressing for decades and early
Forth implementations were often on machines which did not
have eight bit bytes.  Chuck has contrasted this tradition
to C which he points out comes from an 8-bit byte addressing
tradition and has spawned generations of designs to copy
8-bit bytes from one location to another.

The 21 series and the c18 are both examples of word oriented
designs.  In Chuck's software characters went from six bits to
a variable number of bits using Shannon encoding.  There is
very little dealing with 8-bit bytes.

The standard recognizes words and characters and that chars
and words can be the same thing in an ANS compliant system.
By default most Forth run on systems designed for C which
have byte addressing and 8-bit characters or extended
encoding for unicode.  The standard seems to recognize
the word oriented tradition while recognizing the standard
practice of dealing with 8-bit bytes and byte oriented
file and math operations.

It is one of the most obvious differences between the kind
of Forth you see Chuck Moore do and common standard Forth
code.  Chuck deals with bytes and files very infrequently,
he uses words and blocks.

> The main thing I am worried about with 18 bit words is byte
> addressing. =A0

Having word width be a multiple of 8-bits is important when
bytes are what is important.  On the FPGA you can use the
18-bit hardware as 16-bit words with a little more for
parity or other hardware use.

On F21 and P21 I used 20 bit characters most of the time
but sometimes used two 8-bit characters packed into a
20-bit word.  But without a hardware opcode to pack or
unpack bytes eight shifts and masking in software make
the use of bytes not as speed efficient even if it is
more efficient use of memory.   Sometimes I pack
two and a half bytes into word on a 20-bit machine or
on an 18-bit machine I pack two and a quarter bytes
into a word. But packing tightly isn't a good format
for manipulating the data.

> Bytes could be addressed as 8 bit quantities packed into
> an 18 bit word with two bits unused (or used as parity perhaps), or
> they could be 9 bits each. =A09 bit bytes is unusual, but a "byte" is
> not a fixed number of bits. =A0I have also see machines (old ones
> admittedly) with a 36 bit word and 6 bit bytes. =A0I think the bytes
> used for character data was called "field code". =A0This was a way of
> optimizing character data for limited storage. =A0But I think that is
> way too complex for a tiny core CPU.

C comes from a tradition of 8-bit bytes in files.  GCC says right up
front that you want byte addressing.  Forth comes from a word oriented
tradition.  There is some overlap in hosted systems and standards and
probably more in the future as unicode is more widespread.

> I like the idea of 9 bit bytes since that matches the instruction
> width. =A0I'm just wondering if it will make trouble when character data
> is used in arithmetic. =A0To use bytes in arithmetic requires the sign
> bit to be extended. With 9 bit bytes, the question is whether to
> extend the ninth bit or the eighth. Doing one or the other in hardware
> could make the other very awkward. =A0

The big issue I think is using code that was designed around byte
addressing.  Originally there was some code ported to i21 from the FSL
that had been claimed to be portable code but which was clearly
designed
around byte oriented concepts.  It assumed that 8-bits worth carries
into the next 8-bit thing.  It was called portable standard code and
was if words were 16 or 32 bits but the Forth standard says that
non-byte addressing can be standard.  As is the case with a lot of
portable code it wasn't.  Though standard Forth the non-byte
addressing
broke a lot of 'portable' Forth code that had been designed after C
code that had made byte addressing assumptions. The assumptions are
often so ingrained that people look at the code and don't see the
assumptions. At a minimum the code needed a declaration of an
environmental dependency on byte addressing.

> I guess I could just wait until I
> have something to write code for and see how it works. =A0It's not like
> the instruction set is cast in stone at any point. =A0Its also possible
> that it's not need to be done in hardware at all.

You want the hardware to do what is done frequently.  If byte
manipulation
is the target you probably want byte addressing in hardware and logic.

> How does the Intellasys chips use 9 bit addresses? =A0

The address space including all RAM, ROM, and register and multiport
addressing space is 9-bits wide.  When bit-8 is false bit-7 selects
RAM
or ROM and bits 0-5 select one of 64 cells.  When bit-8 is true the
register/port address decoding is selected.

> immediate fields within instructions? =A0

No, only 9-bits of address decoding is used to select RAM/ROM/REG.
Only the bottom 9 bits of R are set on a call or used on a return.

A branch opcode in slot 0 is allocated a 13-bit field.  This covers
all of RAM/ROM/REG and uses a bit to expand "+" into plus with or
without carry. 5+13=3D18

A branch opcode in slot 1 is allocated an 8-bit field.  This is
RAM/ROM but not REG. 5+5+8=3D18

A branch opcode in slot 2 is allocated a 3-bit field which limits
the branch range to the current 8 address page. 5+5+5+3=3D18

On the c18 the three slots offer 13, 8, and 3-bit addressing
fields respectively as 5, 10, and 15 bits are already used for
five bit opcodes.

Things were more complicated on the 21 series because they had
both byte and word addressing.  They booted in byte addressing
mode so one could use an 8-bit ROM or FLASH.  They mapped
the byte loaded into the lowest 8 bits and executed the
instruction in the last slot, the lowest five bits.  And
the branch opcodes in slot 3 occupied the lowest five bits
and used all eight bits as the address field.  So each
branch opcode was limited to eight addresses on the current
8-bit memory page because the branch opcode was part of the
address field.  The lower five bits of the addresses
used by the branch opcodes were opcode bits so you could
only set the three bits above those for addressing in
this 8-bit addressing mode.  It made for ugly boot code
in this 8-bit mode so we tended to just use canned boot
routines to load compiled programs.    I wrote a few
applications that ran entirely from ROM with no RAM but
they were even uglier due to the branch constraints
in the byte addressing mode.

P21 had only 10-bit address fields.  i21/f21 had more
branch options with 10-bit and 14-bit page fields and
home page selection and home page/current 14-bit page
branch mode.  All 21 series used macros for branching
beyond the page address field ranges, # push ;
 =A0
> I guess I am mixing different incarnations.

I hope the branch opcode review helped.

Best Wishes

Article: 137065
Subject: Re: Bit width in CPU cores
From: Coos Haak <chforth@hccnet.nl>
Date: Sun, 21 Dec 2008 20:58:05 +0100
Links: << >>  << T >>  << A >>
Op Sun, 21 Dec 2008 09:32:17 -0800 (PST) schreef m_l_g3:

> On Dec 21, 12:13 pm, rickman <gnu...@gmail.com> wrote:
>> I meant to crosspost to CLF and I also wanted to ask if anyone has
>> looked at similarly making the word size a multiple of 9 rather than 8
>> bits.  That not only matches the BRAMs, but also the multipliers.  Is
>> there any real advantage to this?  I guess this could make it a bit
>> hard to address 8 bit bytes in an 18 bit word.  Or maybe not.
>> Opinions?
>>
> 
> ANS Forth says that address units need not be bytes.
> You may have 18-bit AUs, 9-bit AUs, or 6-bit AUs.
> (In the latter case you will need a fast division by 3 :).

An address unit or character according to the Forth standard is at least 8
bits. So a CDC 6000 would have an environmental dependency here ;-)

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html


Article: 137066
Subject: Re: Why MyHDL?
From: Mike Treseler <mtreseler@gmail.com>
Date: Sun, 21 Dec 2008 12:05:10 -0800
Links: << >>  << T >>  << A >>
Jan Decaluwe wrote:

> A new release is upcoming, and on this occasion
> we have prepared a page about why MyHDL may
> be useful to you:
>     http://www.myhdl.org/doku.php/why

Thanks for the update.
You have been busy!
I agree with the points listed in the link.
For a hardware designer, new to text description,
this is a reasonable and economical path to logic design.

What has always intrigued me about MyHDL is the notion
of verifying clock algorithms using python.
I already do this using plain python
for quickly working out vector widths
and math algorithms for clocked synthesis code.

Of course, my python model is not synthesizable,
but VHDL and Python variables and functions port easily
and a manual conversion is not difficult.

To use MyHDL I would have to give up using variables
and revert to using the .next attribute instead.
While MyHDL is a huge improvement over the
first generation description languages
ABEL, AHDL, CUPL etc),
this is a step I may not be not ready for.

But this is a personal problem.
Most VHDL users don't use variables.

Good luck to you Jan.
When the testbench conversion is ready,
I will give it a try on one of my example designs.

          -- Mike Treseler


Article: 137067
Subject: Re: Why MyHDL?
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Sun, 21 Dec 2008 23:42:46 +0100
Links: << >>  << T >>  << A >>
Mike Treseler wrote:

> To use MyHDL I would have to give up using variables

Most certainly not. On the contrary.

> and revert to using the .next attribute instead.

.next is merely the MyHDL way for signal assignment.

> While MyHDL is a huge improvement over the
> first generation description languages
> ABEL, AHDL, CUPL etc),
> this is a step I may not be not ready for.
> 
> But this is a personal problem.
> Most VHDL users don't use variables.

But they should. As should Verilog designers, and MyHDL
can help them to make that easier.

Mike, it's not like you suggest. Really not. I consider
myself the biggest variable fan (perhaps second to you).
I'm tired of ranting against those stupid rules that
forbid variables in synthesizable Verilog. Why would I
implement an HDL without support for variables?

Of course, with regard to conversion, there are restrictions
regarding the types that can be used. They are documented here:

   http://www.myhdl.org/doc/0.6/manual/conversion.html#supported-types
   http://www.myhdl.org/doc/0.6/manual/conversion.html#intbv-objects

I'm still proud of the following page, which (for once) compares
the use of signals with variables. Warning: to see the point,
you have to read it to the end.

   http://www.myhdl.org/doku.php/cookbook:jc2

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     From Python to silicon:
     http://www.myhdl.org

Article: 137068
Subject: Re: Bit width in CPU cores
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Sun, 21 Dec 2008 16:58:15 -0600
Links: << >>  << T >>  << A >>

>The main thing I am worried about with 18 bit words is byte
>addressing.

Why?  What sort of code are you going to run?

Are you planning to do string processing?  If so, what's wrong
with 9 bit bytes?  (just ignore the extra bit)

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 137069
Subject: Re: FPGA for Contoll
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Sun, 21 Dec 2008 17:00:01 -0600
Links: << >>  << T >>  << A >>

>Is FPGA a good choice for control applications like contrloling
>electric gates , microvaves, industrial nachinery etc , or this niche is 
>best done by regular microcontrollers like 8051 etc ?

In general, if you can do it in a microprocessor, that's probably
the cheaper/quicker way to do it.  It's much easier to hire
software guys than hardware guys.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 137070
Subject: Re: Why MyHDL?
From: Mike Treseler <mtreseler@gmail.com>
Date: Sun, 21 Dec 2008 16:01:27 -0800
Links: << >>  << T >>  << A >>
Jan Decaluwe wrote:
> Mike Treseler wrote:
> 
>> To use MyHDL I would have to give up using variables
> 
> Most certainly not. On the contrary.

I mean in the MyHDL *source*,
not the generated code.

Maybe I'm wrong.
I'll look thru the examples again.

     -- Mike Treseler


Article: 137071
Subject: Re: Bit width in CPU cores
From: rickman <gnuarm@gmail.com>
Date: Sun, 21 Dec 2008 21:43:39 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 21, 2:45=A0pm, foxchip <f...@ultratechnology.com> wrote:
> On Dec 21, 9:33=A0am, rickman <gnu...@gmail.com> wrote:
>
> > Opinions?
>
> I see two issues; FPGA and Forth. =A0There is the issue that many
> FPGA offer 18-bit wide logic that can easily be used for 18b-bit
> wide memory and math. =A0There is the issue that Forth comes from
> a tradition of being word oriented both at the semantic level
> and evaluation level.
>
> Chuck has said that Forth is word oriented and that we should
> recognize that and take advantage of it. =A0All his hardware and
> software has been word addressing for decades and early
> Forth implementations were often on machines which did not
> have eight bit bytes. =A0Chuck has contrasted this tradition
> to C which he points out comes from an 8-bit byte addressing
> tradition and has spawned generations of designs to copy
> 8-bit bytes from one location to another.
>
> The 21 series and the c18 are both examples of word oriented
> designs. =A0In Chuck's software characters went from six bits to
> a variable number of bits using Shannon encoding. =A0There is
> very little dealing with 8-bit bytes.
>
> The standard recognizes words and characters and that chars
> and words can be the same thing in an ANS compliant system.
> By default most Forth run on systems designed for C which
> have byte addressing and 8-bit characters or extended
> encoding for unicode. =A0The standard seems to recognize
> the word oriented tradition while recognizing the standard
> practice of dealing with 8-bit bytes and byte oriented
> file and math operations.
>
> It is one of the most obvious differences between the kind
> of Forth you see Chuck Moore do and common standard Forth
> code. =A0Chuck deals with bytes and files very infrequently,
> he uses words and blocks.
>
> > The main thing I am worried about with 18 bit words is byte
> > addressing. =A0
>
> Having word width be a multiple of 8-bits is important when
> bytes are what is important. =A0On the FPGA you can use the
> 18-bit hardware as 16-bit words with a little more for
> parity or other hardware use.
>
> On F21 and P21 I used 20 bit characters most of the time
> but sometimes used two 8-bit characters packed into a
> 20-bit word. =A0But without a hardware opcode to pack or
> unpack bytes eight shifts and masking in software make
> the use of bytes not as speed efficient even if it is
> more efficient use of memory. =A0 Sometimes I pack
> two and a half bytes into word on a 20-bit machine or
> on an 18-bit machine I pack two and a quarter bytes
> into a word. But packing tightly isn't a good format
> for manipulating the data.
>
> > Bytes could be addressed as 8 bit quantities packed into
> > an 18 bit word with two bits unused (or used as parity perhaps), or
> > they could be 9 bits each. =A09 bit bytes is unusual, but a "byte" is
> > not a fixed number of bits. =A0I have also see machines (old ones
> > admittedly) with a 36 bit word and 6 bit bytes. =A0I think the bytes
> > used for character data was called "field code". =A0This was a way of
> > optimizing character data for limited storage. =A0But I think that is
> > way too complex for a tiny core CPU.
>
> C comes from a tradition of 8-bit bytes in files. =A0GCC says right up
> front that you want byte addressing. =A0Forth comes from a word oriented
> tradition. =A0There is some overlap in hosted systems and standards and
> probably more in the future as unicode is more widespread.
>
> > I like the idea of 9 bit bytes since that matches the instruction
> > width. =A0I'm just wondering if it will make trouble when character dat=
a
> > is used in arithmetic. =A0To use bytes in arithmetic requires the sign
> > bit to be extended. With 9 bit bytes, the question is whether to
> > extend the ninth bit or the eighth. Doing one or the other in hardware
> > could make the other very awkward. =A0
>
> The big issue I think is using code that was designed around byte
> addressing. =A0Originally there was some code ported to i21 from the FSL
> that had been claimed to be portable code but which was clearly
> designed
> around byte oriented concepts. =A0It assumed that 8-bits worth carries
> into the next 8-bit thing. =A0It was called portable standard code and
> was if words were 16 or 32 bits but the Forth standard says that
> non-byte addressing can be standard. =A0As is the case with a lot of
> portable code it wasn't. =A0Though standard Forth the non-byte
> addressing
> broke a lot of 'portable' Forth code that had been designed after C
> code that had made byte addressing assumptions. The assumptions are
> often so ingrained that people look at the code and don't see the
> assumptions. At a minimum the code needed a declaration of an
> environmental dependency on byte addressing.
>
> > I guess I could just wait until I
> > have something to write code for and see how it works. =A0It's not like
> > the instruction set is cast in stone at any point. =A0Its also possible
> > that it's not need to be done in hardware at all.
>
> You want the hardware to do what is done frequently. =A0If byte
> manipulation
> is the target you probably want byte addressing in hardware and logic.
>
> > How does the Intellasys chips use 9 bit addresses? =A0
>
> The address space including all RAM, ROM, and register and multiport
> addressing space is 9-bits wide. =A0When bit-8 is false bit-7 selects
> RAM
> or ROM and bits 0-5 select one of 64 cells. =A0When bit-8 is true the
> register/port address decoding is selected.
>
> > immediate fields within instructions? =A0
>
> No, only 9-bits of address decoding is used to select RAM/ROM/REG.
> Only the bottom 9 bits of R are set on a call or used on a return.
>
> A branch opcode in slot 0 is allocated a 13-bit field. =A0This covers
> all of RAM/ROM/REG and uses a bit to expand "+" into plus with or
> without carry. 5+13=3D18
>
> A branch opcode in slot 1 is allocated an 8-bit field. =A0This is
> RAM/ROM but not REG. 5+5+8=3D18
>
> A branch opcode in slot 2 is allocated a 3-bit field which limits
> the branch range to the current 8 address page. 5+5+5+3=3D18
>
> On the c18 the three slots offer 13, 8, and 3-bit addressing
> fields respectively as 5, 10, and 15 bits are already used for
> five bit opcodes.
>
> Things were more complicated on the 21 series because they had
> both byte and word addressing. =A0They booted in byte addressing
> mode so one could use an 8-bit ROM or FLASH. =A0They mapped
> the byte loaded into the lowest 8 bits and executed the
> instruction in the last slot, the lowest five bits. =A0And
> the branch opcodes in slot 3 occupied the lowest five bits
> and used all eight bits as the address field. =A0So each
> branch opcode was limited to eight addresses on the current
> 8-bit memory page because the branch opcode was part of the
> address field. =A0The lower five bits of the addresses
> used by the branch opcodes were opcode bits so you could
> only set the three bits above those for addressing in
> this 8-bit addressing mode. =A0It made for ugly boot code
> in this 8-bit mode so we tended to just use canned boot
> routines to load compiled programs. =A0 =A0I wrote a few
> applications that ran entirely from ROM with no RAM but
> they were even uglier due to the branch constraints
> in the byte addressing mode.
>
> P21 had only 10-bit address fields. =A0i21/f21 had more
> branch options with 10-bit and 14-bit page fields and
> home page selection and home page/current 14-bit page
> branch mode. =A0All 21 series used macros for branching
> beyond the page address field ranges, # push ;
> =A0=A0
>
> > I guess I am mixing different incarnations.
>
> I hope the branch opcode review helped.
>
> Best Wishes

Jeff,

Thanks for the reply.  I appreciate your insight.  I know you likely
have more experience in this area than anyone else and your
perspective is always of interest.

Rick

Article: 137072
Subject: Re: Bit width in CPU cores
From: rickman <gnuarm@gmail.com>
Date: Sun, 21 Dec 2008 21:47:21 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 21, 1:48=A0pm, Elizabeth D Rather <erat...@forth.com> wrote:
> rickman wrote:
>
> ...
>
> > How does the Intellasys chips use 9 bit addresses? =A0Are these just
> > immediate fields within instructions? =A0I have trouble remembering the
> > details of the various Forth CPUs, but I want to say the Intellasys
> > chip is one of Chuck Moore's designs and uses a full word for an
> > instruction that contains immediate data/address. =A0But that would be =
5
> > bit instruction and 13 bit immediate. =A0That doesn't seem to match.
> > Besides, I want to say that was in the context of a 20 bit instruction
> > word. =A0I guess I am mixing different incarnations.
>
> Remember, each core has only 64 words of RAM and 64 words of ROM. =A0From
> the Data Sheet concerning branches:
>
> The size and interpretation of the branch address field is affected by
> opcode packing. The field is always right justified within the same
> instruction word as the opcode that controls it. The slot number of the
> branch opcode will determine the number of high order bits available to
> the address field. Each of the branch cases, and its affect upon address
> size and effective address calculation, are illustrated in Table 3.4.
>
> Example 1: If the opcode is in Slot 0, there is room for a full nine
> bits of address and a tenth bit to set extended mode.
>
> Example 2: In Slot 1, there is room for eight address bits. Note that
> eight bits will reach all of RAM and ROM, but cannot reach the I/O
> ports. In other words, P8 is always set to 0 when branching from slot 1.
> P9 is not affected by Slot 2 banches.
>
> Example 3: In Slot 2, 3 address bits are available. These three bits are
> combined with five bits of the P register to form an 8-bit address. P8
> is set to 0 when branching from Slot 2. Note that the address is in the
> same 8- word page as the value of the P register when the opcode
> executes. P9 is not affected by Slot 2 banches.
>
> --------
>
> Direct addressing uses the 9-bit B register.
>
> Cheers,
> Elizabeth

Thanks for the review.  It is pretty amazing how much this processor
can do with so little.

Rick

Article: 137073
Subject: Re: Bit width in CPU cores
From: rickman <gnuarm@gmail.com>
Date: Sun, 21 Dec 2008 22:10:54 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 21, 5:58=A0pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
> >The main thing I am worried about with 18 bit words is byte
> >addressing.
>
> Why? =A0What sort of code are you going to run?

That's a good question.  The initial app is for processing a time code
signal.  This consists of managing timing which will be control code
and extracting and updating the time code data which is mostly BCD.
The initially implemented version of the time codes signal is pretty
slow with only 100 bits per sec.  The CODEC sample rate is 8 kHz and I
would like to also do the processing to mod/demod the signal.

Actually, this is a potential paid app, but is not likely to be the
first.  The first is going to be part of a test fixture for the
modules which are currently being built for the time code signal app.
There may be some character processing, but not much.  However, I
don't want to hamstring later apps and I prefer to make the processor
as flexible as practical now.

> Are you planning to do string processing? =A0If so, what's wrong
> with 9 bit bytes? =A0(just ignore the extra bit)

If it is just doing string processing, ignoring the 9th bit will work
fine.  I guess I am very much used to the C mindset of supporting
signed and unsigned byte data.  I can't say it is important to do any
of this.  But I intended to provide a byte read from memory with sign
extension.  So it may matter whether the eighth bit or the ninths bit
is used for sign extension.  The more I think of it, the more I feel
like I am over-thinking it.  Maybe I should just get something going
and fine tune it later.  After all, this is already round three of the
design.

Rick

Article: 137074
Subject: Re: Synthesis Problem
From: Andreas Ehliar <ehliar-nospam@isy.liu.se>
Date: Mon, 22 Dec 2008 06:33:58 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 2008-12-22, Digi Suji <digisuji@gmail.com> wrote:
> Hi,
>
> I am using Xilinx XST to synthesize my design. Post-synthesis
> simulation is not matching pre-synthesis simulation. I figured out
> where the problem is. But I do not understand how to trouble shoot
> this.

Think of it as the synthesis tool being clever. Since you are assigning
don't cares (x) to the outputs when wb_we_i is 1, the synthesis tool can
assign whatever value it wants to these outputs. The most optimal way to
implement this in your circuit is simply to ignore wb_we_i.

So the synthesis tool did nothing wrong here.

/Andreas



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
2017JanFebMarApr2017

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