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
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, JamieArticle: 137051
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? AnttiArticle: 137052
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
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? kadhiemArticle: 137054
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 ecArticle: 137055
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 AnttiArticle: 137056
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, LorenzArticle: 137057
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: 137058Thanks 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, > > LorenzArticle: 137059
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). -- JecelArticle: 137060
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
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. RickArticle: 137062
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: 137063rickman 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
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 WishesArticle: 137065
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.htmlArticle: 137066
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
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>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
>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
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: 137071On 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. RickArticle: 137072
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. RickArticle: 137073
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. RickArticle: 137074
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:
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