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
On Dec 21, 12:32 pm, m_l_g3 <m_l...@yahoo.com> wrote: > 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 ;) Thanks for your comments. I am aware of how instruction encoding can be used to minimize memory bandwidth, but that is not a concern in this design. The instruction fetch has a separate memory interface and runs as fast as the CPU. Fetching more than one instruction at a time just adds to the logic required to process instructions. One of the main goals is to minimize the logic use. In fact, I spent a lot of time trying to optimize the opcode assignments to minimize the decode required. So analysis of the instruction frequency was used, but to figure the best encoding. According to Koopman's data the most common instruction was LIT. So this was encoded as 1 bit with the rest of the instruction as data. The call and jump instructions also have a data field leaving 32 opcodes for other instructions. With the addition of the ninth bit the return function can be done as a parallel operation if the return stack is not being used by the main opcode. Not the most efficient use of a bit, but this bit is virtually free. RickArticle: 137076
rickman wrote: > On Dec 21, 5:58 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal > Murray) wrote: ... >> Are you planning to do string processing? If so, what's wrong >> with 9 bit bytes? (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. You don't have 9-bit bytes (although you do have 9-bit addresses). You don't have "bytes" at all. As far as data is concerned, you have 18-bit words (read Jeff's message again). If you're reading packed BCD, you have the option of taking apart those words, but if you're getting individual BCD packets it may be easier just to leave them one per word. Depends on what you're doing with them. 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: 137077
On Sun, 21 Dec 2008 05:03:12 -0600, Hal Murray wrote:
> In article
> <46017e00-ae8e-45d7-945f-020dd34b6483@20g2000yqt.googlegroups.com>,
> rickman <gnuarm@gmail.com> writes:
>
> 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)
I followed up on Sweet and Sandman's work with the MESA instruction set
(R E Sweet and J G Sandman, "Empirical Analysis of the MESA Instruction
Set". ACM Symposium on Architectural Support for Programming Languages
and Operating Systems, March 1982, 235-243).
My PhD dissertation ("A methodology for automated design of computer
instruction sets") provided a generic method to optimize instruction sets
for code space. It's online at
http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-129.html
Some of my research students carried out further work in the 1980s and
1990s: look for papers by Olaf Schoepke and Francesco Arci.
Massalin's paper on superoptimizers is also useful (H Massalin,
"Superoptimizer - A Look at the World's Smallest Program", Computer
Architecture News, 15, 122-126, October 1987). He concluded that rich use
of condition code flags was key to compact code.
More recently a number of companies have emerged offering commercial
products which can optimize instruction sets. Critical Blue and Mimosys
are examples, although they tend to optimize for performance rather than
code space.
Hope this is of interest,
Jeremy
Article: 137078Hi, 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. Below is one of the always block in my design. In pre-synthesis simulation, if wb_we_i is not equal to 0, then the simulator executes the "else block" and assigns wb_dat_o with "8'bx" value. If it is 1 then simulator executes "if block". In post synthesis simulation, irrespective of the value of wb_we_i(0 or 1), the simulator executes only "if block". I do not understand why it is happening. Please help. always @(posedge wb_clk_i) begin if (wb_we_i==0) case (wb_adr_i) // synopsis parallel_case 3'b000: wb_dat_o <= prer[ 7:0]; 3'b001: wb_dat_o <= prer[15:8]; 3'b010: wb_dat_o <= ctr; 3'b011: wb_dat_o <= rxr; // write is transmit register (txr) 3'b100: wb_dat_o <= sr; // write is command register (cr) 3'b101: wb_dat_o <= txr; 3'b110: wb_dat_o <= cr; 3'b111: wb_dat_o <= 0; // reserved endcase else case (wb_adr_i) 3'b000: wb_dat_o <= 8'bx; 3'b001: wb_dat_o <= 8'bx; 3'b010: wb_dat_o <= 8'bx; 3'b011: wb_dat_o <= 8'bx; 3'b100: wb_dat_o <= 8'bx; 3'b101: wb_dat_o <= 8'bx; 3'b110: wb_dat_o <= 8'bx; 3'b111: wb_dat_o <= 8'bx; endcase end I am using ModelSim PE Verilog student edition to simulate the netlist and it is throwing an error "# ** Warning: Design size of 47649 statements or 3176 leaf instances exceeds ModelSim PE Student Edition recommended capacity. # Expect performance to be quite adversely affected.". Is this a possible reason? Please help. ThanksArticle: 137079
Mike Treseler wrote:
> 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.
No, .next is only for signals. Other types of objects and
assignments are supported by the convertor, and (only) those
map to variables.
Now, neither Python nor MyHDL currently support your favorite
coding style of local interfaceless procedures. This is because
of Python's current scoping rules. Perhaps that explains some
of the confusion?
Below is a small example of how MyHDL currently supports
variables that keep state, as compared to a signal. The
generated VHDL code is added. Hopefully this will make
it clearer:
============================================================
from myhdl import *
def Example(clock, reset):
count_sig = Signal(intbv(0)[8:])
@instance
def logic():
count_var = intbv(0)[8:]
while True:
yield clock.posedge, reset.negedge
if reset == 0:
count_sig.next = 0
count_var[:] = 0
else:
assert count_sig == count_var # equal
count_sig.next = count_sig + 1
count_var += 1
assert count_sig == count_var - 1 # different!
return logic
=============================================================
The generated VHDL code:
========================================================
-- File: Example.vhd
-- Generated by MyHDL 0.6
-- Date: Mon Dec 22 11:12:11 2008
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
use std.textio.all;
use work.pck_myhdl_06.all;
entity Example is
port (
clock: in std_logic;
reset: in std_logic
);
end entity Example;
architecture MyHDL of Example is
signal count_sig: unsigned(7 downto 0);
begin
EXAMPLE_LOGIC: process (clock, reset) is
variable count_var: unsigned(7 downto 0);
begin
if (reset = '0') then
count_sig <= "00000000";
count_var := "00000000";
elsif rising_edge(clock) then
assert (count_sig = count_var)
report "*** AssertionError ***"
severity error;
count_sig <= (count_sig + 1);
count_var := (count_var + 1);
assert (count_sig = (count_var - 1))
report "*** AssertionError ***"
severity error;
end if;
end process EXAMPLE_LOGIC;
end architecture MyHDL;
=====================================================
--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a hardware description language:
http://www.myhdl.org
Article: 137080
On Mon, 22 Dec 2008 01:40:43 -0800 (PST), Digi Suji wrote:
>Below is one of the always block in my design. In pre-synthesis
>simulation, if wb_we_i is not equal to 0, then the simulator executes
>the "else block" and assigns wb_dat_o with "8'bx" value. If it is 1
>then simulator executes "if block". In post synthesis simulation,
>irrespective of the value of wb_we_i(0 or 1), the simulator executes
>only "if block". I do not understand why it is happening. Please help.
>
>always @(posedge wb_clk_i)
>begin
>if (wb_we_i==0)
>case (wb_adr_i) // synopsis parallel_case
>3'b000: wb_dat_o <= prer[ 7:0];
[snip]
>endcase
>else
>case (wb_adr_i)
>3'b000: wb_dat_o <= 8'bx;
[snip]
>endcase
>end
The "else" branch assigns X to your output. The synth tool
thinks this means "don't care" and performs an optimisation
so that the output of your always block is correct for
wb_we_i==0, but gives you the same output when wb_we_i==1.
Why is this a problem for you? As soon as you change some
of the outputs in the "else" branch, the tool will be forced
to build the necessary extra logic.
Note also that you have another potential mismatch: the
case statements have no default branch, so you may see
latching behaviour in simulation if wb_adr_i has some
X or Z bits. It is better to make a default assignment
to the output:
always @(posedge wb_clk_i)
begin
wb_dat_o <= 8'bx; ///// DEFAULT ASSIGNMENT
// Now you go on to specify all the situations
// for which you need a particular output value:
if (wb_we_i==0)
case (wb_adr_i) // synopsis parallel_case
3'b000: wb_dat_o <= prer[ 7:0];
3'b001: wb_dat_o <= prer[15:8];
3'b010: wb_dat_o <= ctr;
3'b011: wb_dat_o <= rxr; // write is transmit register (txr)
3'b100: wb_dat_o <= sr; // write is command register (cr)
3'b101: wb_dat_o <= txr;
3'b110: wb_dat_o <= cr;
3'b111: wb_dat_o <= 0; // reserved
endcase
end
Synthesis cannot drive "X" on to an output - there is
no such value in hardware - so the synth tool will assume
that X means don't-care and will choose whichever combination
of 1s and 0s comes closest to meeting its optimisation goals.
In this situation, that means the output will be identical for
wb_we_i==0 and wb_we_i==0; that input will simply be ignored.
Note also that "synopsis parallel_case" is mis-spelt
and therefore will have no effect (pragmas! I hate 'em!)
and in any event it is pointless to put parallel_case
on a case statement that is inherently parallel.
>I am using ModelSim PE Verilog student edition to simulate the netlist
>and it is throwing an error "# ** Warning: Design size of 47649
>statements or 3176 leaf instances exceeds ModelSim PE Student Edition
>recommended capacity.
># Expect performance to be quite adversely affected.". Is this a
>possible reason? Please help.
This means exactly what it says. The student version of ModelSim
is fully functional but is artificially hobbled: its performance
will get spectacularly worse if you exceed its size limits.
Presumably you got that message for post-synthesis simulation?
ModelSim has absolutely no effect on the synthesised logic,
of course.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 137081HI I have a PCB which has a TI IC for the PHY layer controller and I want to connect the PCB with the Virtex II xc2v8000 FPGA. But I need information about the I/O Standard of the Virtex II. The output ports on the PCB are Bidirectional and they accept 4.4 volts I/O Standard but I checked the datasheet of the virtex II Chip and I found that the maximum volts for the output and input are 3.3 Volts for the FPGA pins. Can any one help me with this problem. I want to know if i connect the PCB board with the FPGA pins, will the PCB burn the I/O pins of the FPGA.Article: 137082
kashif <comzian@hotmail.com> wrote: >HI >I have a PCB which has a TI IC for the PHY layer controller and I want to >connect the PCB with the Virtex II xc2v8000 FPGA. But I need information >about the I/O Standard of the Virtex II. The output ports on the PCB are >Bidirectional and they accept 4.4 volts I/O Standard but I checked the >datasheet of the virtex II Chip and I found that the maximum volts for the >output and input are 3.3 Volts for the FPGA pins. >Can any one help me with this problem. >I want to know if i connect the PCB board with the FPGA pins, will the PCB >burn the I/O pins of the FPGA. You can connect LVTTL output to TTL input. And TTL output to LVTTL input with a current limiting resistor in series, protection diode max current dependent. In the case of bidirectional communication use the last method. However pay attention to the rise times. In general just have a look at the voltage levels. Max currents etc.Article: 137083
On Dec 22, 2:24=A0am, Elizabeth D Rather <erat...@forth.com> wrote: > rickman wrote: > > On Dec 21, 5:58 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal > > Murray) wrote: > ... > >> 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. =A0I guess I am very much used to the C mindset of supporting > > signed and unsigned byte data. =A0I can't say it is important to do any > > of this. =A0But I intended to provide a byte read from memory with sign > > extension. =A0So it may matter whether the eighth bit or the ninths bit > > is used for sign extension. =A0The more I think of it, the more I feel > > like I am over-thinking it. =A0Maybe I should just get something going > > and fine tune it later. =A0After all, this is already round three of th= e > > design. > > You don't have 9-bit bytes (although you do have 9-bit addresses). =A0You > don't have "bytes" at all. =A0As far as data is concerned, you have 18-bi= t > words (read Jeff's message again). =A0If you're reading packed BCD, you > have the option of taking apart those words, but if you're getting > individual BCD packets it may be easier just to leave them one per word. > =A0 Depends on what you're doing with them. > > Cheers, > Elizabeth Yes, I understand how the Intelasys device. I am talking about my CPU design. I have no plans to use a commercial CPU. I am asking about designing a CPU to implement in an FPGA with no external memory. RickArticle: 137084
On Dec 21, 8:32=A0am, "RealInfo" <therighti...@yahoo.com> 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 ? Like Hal said, if you can do it in a micro you are likely better off doing it that way. About the only limitation that a micro has is speed. A micro executes instructions sequentially and can only "emulate" things happening in parallel. If the timing of your processing requires things to be done in a short timeframe or synchronized to an extent that a micro can't do, then you will need an FPGA. MCUs are very cheap and come in a *very* wide range of CPU performance, memory size and peripherals that is unmatched by any other types of devices. Certainly microwave ovens have no requirements that would mandate an FPGA. I can't say anything about "industrial machinery" because that can vary widely. RickArticle: 137085
I am revieiwing someone elses code and wanted to know the behaviour of
following code. Your comments are greatly appreciated. I normally am
familiar with <= type assignment.
//Register some of the data coming from other modules for data
integrity
always @(UsbIfClk) begin
if(~Res_N) begin
CreateMailboxTest = 1'h0;
StopMailboxTest = 1'h0;
MailboxDataValid = 1'h0;
ResetRxBram = 1'h0;
end
else begin
CreateMailboxTest = MTC_CreateMailboxTest;
StopMailboxTest = MTC_StopMailboxTest;
MailboxDataValid = AMR_MailboxDataValid;
ResetRxBram = ((MTC_CreateMailboxTest &
ClearStaleData) | AMR_ResetRxBram);
end
end
Article: 137086On Mon, 22 Dec 2008 09:31:39 -0800 (PST), cpandya@yahoo.com wrote: >I am revieiwing someone elses code and wanted to know the behaviour of >following code. Your comments are greatly appreciated. I normally am >familiar with <= type assignment. > >//Register some of the data coming from other modules for data >integrity > always @(UsbIfClk) begin > if(~Res_N) begin > CreateMailboxTest = 1'h0; > StopMailboxTest = 1'h0; > MailboxDataValid = 1'h0; > ResetRxBram = 1'h0; > end > else begin > CreateMailboxTest = MTC_CreateMailboxTest; > StopMailboxTest = MTC_StopMailboxTest; > MailboxDataValid = AMR_MailboxDataValid; > ResetRxBram = ((MTC_CreateMailboxTest & >ClearStaleData) | AMR_ResetRxBram); > end > end I'd say it is unacceptable code if, as seems to be the case, it's intended to be RTL logic. If it's testbench code, then there just possibly might be a good reason for it. Bad choice #1: It is _never_ safe or sensible to use blocking assignment (=) to assign to a variable in a clocked block if that variable will be used (read) in any other always block that is clocked by the same clock event. Since you can't know how the block's outputs will be used when you write the block, it is stupid to expose yourself to the risk that someone might use those outputs in another clocked block, which would surely give rise to mismatches between synthesis and simulation. Bad choice #2: This code implies double-edge triggering of the registers, since there is no posedge or negedge edge-detector in the sensitivity list (event control). This is unlikely to be appropriate. You should ask the designer to justify these two choices. If the justification seems good to you, then perhaps you could be kind enough to post it here - I'm sure many of us would be interested to see it :-) -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 137087
On Mon, 22 Dec 2008 10:24:06 +0000, Jonathan Bromley wrote: >Note also that you have another potential mismatch: the >case statements have no default branch, so you may see >latching behaviour in simulation if wb_adr_i has some >X or Z bits. Please accept my apologies: this comment is wrong. It was a knee-jerk reaction when I saw the incomplete case statement, but in fact it's not really important because the always block is clocked, not combinational. It remains the case that you may wish to consider what is supposed to happen when the case statement gets X or Z values on its input expression. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 137088
The most interesting part is going to happen after you start implementing the file i/o. The external stuff, including disks, rs-232 and Ethernet, usually is 8-bit. Well, 9 bytes will make 8 9-bit entities, provided that you re-pack them.Article: 137089
On Dec 21, 10:45=A0pm, foxchip <f...@ultratechnology.com> wrote: > 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 almost never use CHARS because there is no way to make sure that the code would work on a system where 1 AU <> 1 CHARS. If you develop code for a machine that addresses, say, nibbles, you have a chance to try your code on the desktop and see if it works. If you develop on a desktop, where will you get a system with 6-bit AUs? So, all code that had never been tried on a system where 1 char <> 1 au, has an environmental dependency on byte addressing. From jethomas5@gmail.com Mon Dec 22 13:36:14 2008 Path: flpi142.ffdc.sbc.com!flph199.ffdc.sbc.com!prodigy.com!flph200.ffdc.sbc.com!prodigy.net!bigfeed.bellsouth.net!news.bellsouth.net!cyclone1.gnilink.net!gnilink.net!nx01.iad.newshosting.com!newshosting.com!69.16.185.16.MISMATCH!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!newsfe04.iad.POSTED!7564ea0f!not-for-mail From: Jonah Thomas <jethomas5@gmail.com> Newsgroups: comp.arch.fpga,comp.lang.forth Subject: Re: Bit width in CPU cores Message-Id: <20081222163614.14fdc77e.jethomas5@gmail.com> References: <46017e00-ae8e-45d7-945f-020dd34b6483@20g2000yqt.googlegroups.com> <75669cf2-3e14-453e-9b3d-e1cbca5285dd@e18g2000yqo.googlegroups.com> <0f520659-c7aa-4dec-8ca7-392f9be94c05@s36g2000vbp.googlegroups.com> <610b27d0-d69f-4507-8b01-ec46fef616ad@n10g2000yqm.googlegroups.com> <8ee060dd-f026-42f9-9ae1-3f3926c1f5dc@v31g2000vbb.googlegroups.com> <19328855-4fb7-438e-81fd-6ee8e74ea400@r10g2000prf.googlegroups.com> X-Newsreader: Sylpheed version 0.9.3 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Lines: 28 NNTP-Posting-Host: 72.196.198.155 X-Complaints-To: newsmaster@cox.net X-Trace: newsfe04.iad 1229981962 72.196.198.155 (Mon, 22 Dec 2008 21:39:22 UTC) NNTP-Posting-Date: Mon, 22 Dec 2008 21:39:22 UTC Organization: Cox Date: Mon, 22 Dec 2008 16:36:14 -0500 Xref: prodigy.net comp.arch.fpga:150048 comp.lang.forth:139129 X-Received-Date: Mon, 22 Dec 2008 16:39:23 EST (flpi142.ffdc.sbc.com) m_l_g3 <m_l_g3@yahoo.com> wrote: > I almost never use CHARS because there is no way to make sure that > the code would work on a system where 1 AU <> 1 CHARS. > If you develop code for a machine that addresses, say, nibbles, > you have a chance to try your code on the desktop and see > if it works. If you develop on a desktop, where will you > get a system with 6-bit AUs? In theory, this should not be a problem. If you use CHARS every time you ought to, then your code ought to run on other systems because the system will use CHARS to translate from address units to characters in the places you need it to. > So, all code that had never been tried on a system where 1 char <> 1 > au, has an environmental dependency on byte addressing. In practice, if you try to use CHARS correctly but you leave one out, how would you notice? A Forth that does type-checking would find the problem for you. Otherwise you depend on your desk-checking skills without actually getting the machine to test for the problem. Unless you have a Forth system with different addressing. For awhile I religiously used CHARS and then I quit. I wasn't sure I was doing it completely right, and I wasn't sure it was worth it. Make an environmental dependency on byte adddressing, and if anybody wants to port your code they know they have this issue to deal with. Why claim you've handled it when you might not have?Article: 137090
On Dec 22, 4:16=A0pm, m_l_g3 <m_l...@yahoo.com> wrote: > The most interesting part is going to happen after > you start implementing the file i/o. > > The external stuff, including disks, rs-232 and Ethernet, > usually is 8-bit. Well, 9 bytes will make 8 9-bit entities, > provided that you re-pack them. I considered this, but what type of 9 bit entities are needed? The instructions are 9 bits which can be packed or may be sent as 9 bit data depending on your media. Async serial can be used to send 9 bit data in any of a number of ways. When storing images on disk, they are often stored as ASCII hex data anyway, although I don't know of any formats that directly support an arbitrary number of bits per word. Yeah, I guess this is going to require some inventiveness. RickArticle: 137091
Dear All, I'm trying to make a peripheral in XPS. I've used the "Create or Import Peripheral" wizard to create the peripheral. I can also get the thing to compile and I also successfully added the IP to my MicroBlaze design. However, now I want to add more advanced stuff to the peripheral and therefor need to add userports. I just don't know how to do it. I have added some ports in the IP Entity and also added them in the MPD file. But still nothing shows in the "System Assembly View" when I add the IP. Only the ports that was already there. Can anyone tell me what the flow is to add extra ports? Thank you in advance and Merry Christmas Regards JanArticle: 137092
On Dec 22, 10:53=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Mon, 22 Dec 2008 10:24:06 +0000, Jonathan Bromley wrote: > >Note also that you have another potential mismatch: the > >case statements have no default branch, so you may see > >latching behaviour in simulation if wb_adr_i has some > >X or Z bits. > > Please accept my apologies: this comment is wrong. > It was a knee-jerk reaction when I saw the incomplete > case statement, but in fact it's not really important > because the always block is clocked, not combinational. > > It remains the case that you may wish to consider > what is supposed to happen when the case statement > gets X or Z values on its input expression. > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. Thank you very much Andreas and Jonathan. Your suggestions helped me. I just replace "8'bx" with "8'bz" and post synthesis simulation is working as expected. Thanks again Sujith ChakraArticle: 137093
Op Mon, 22 Dec 2008 14:02:34 -0800 (PST) schreef rickman: > On Dec 22, 4:16 pm, m_l_g3 <m_l...@yahoo.com> wrote: >> The most interesting part is going to happen after >> you start implementing the file i/o. >> >> The external stuff, including disks, rs-232 and Ethernet, >> usually is 8-bit. Well, 9 bytes will make 8 9-bit entities, >> provided that you re-pack them. > > I considered this, but what type of 9 bit entities are needed? The > instructions are 9 bits which can be packed or may be sent as 9 bit > data depending on your media. Async serial can be used to send 9 bit > data in any of a number of ways. When storing images on disk, they > are often stored as ASCII hex data anyway, although I don't know of > any formats that directly support an arbitrary number of bits per > word. > > Yeah, I guess this is going to require some inventiveness. > What are ASCII hex data? ASCII art perhaps? Wouldn't images be stored as binary instead of 7 bit character codes? -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.htmlArticle: 137094
> The question is whether there is a better way to use this extra bit > in an instruction. I am sure it would not be productive to just add > more opcodes. I haven't seen any other ideas in any designs I have > read about, so the RET function seems like the best. If your architecture is a pipelined approach (which I guess it isn't) then the extra bit could serve as a hint for a simple branch prediction logic. ArnimArticle: 137095
On Dec 22, 2:07=A0pm, Jan <1...@2.3> wrote: > Dear All, > > I'm trying to make a peripheral in XPS. I've used the "Create or Import > Peripheral" wizard to create the peripheral. > I can also get the thing to compile and I also successfully added the IP > to my MicroBlaze design. > > However, now I want to add more advanced stuff to the peripheral and > therefor need to add userports. I just don't know how to do it. I have > added some ports in the IP Entity and also added them in the MPD file. > > But still nothing shows in the "System Assembly View" when I add the IP. > Only the ports that was already there. > > Can anyone tell me what the flow is to add extra ports? > > Thank you in advance and Merry Christmas > > Regards > =A0 =A0Jan Hi, Did you add the PORT(s) to your IP instance in the MHS file? If you don't add the PORT(s) to the IP instance in the MHS file, then they won't show up in the "Ports" tab in XPS. Another way to get the ports to show up is to re-import the IP in XPS. This will only work if you've added the ports in the top-level IP HDL file and the MPD file. Thanks, JeremyArticle: 137096
On Dec 22, 8:03=A0pm, Arnim <clv.5.min...@spamgourmet.com> wrote: > > The question is whether there is a better way to use this extra bit > > in an instruction. =A0I am sure it would not be productive to just add > > =A0more opcodes. =A0I haven't seen any other ideas in any designs I hav= e > > =A0read about, so the RET function seems like the best. > > If your architecture is a pipelined approach (which I guess it isn't) > then the extra bit could serve as a hint for a simple branch prediction > logic. No, it's not pipelined. It runs pretty fast already. I had an implementation in a very old ACEX 1K part running over 50 MHz with async memory. Using a current part with synchronous memory I am thinking it will run closer to 100 MHz. No branch prediction needed. RickArticle: 137097
All, I'm using EDK 10.1, specced for the ML501. When I reach the mapping phase, I get the following error (several times): ERROR:PhysDesignRules:1492 - Incompatible programming for comp mb_plb_M_ABus<1>. The pair of luts SLICEL_A5LUT and SLICEL_A6LUT must have a compatible equation, lower bits must be programmed the same. The SLICEL_A5LUT hex equation is <O5=0x08080808> and the SLICEL_A6LUT hex equation is <O6=0x607AA67800008888>. I found the following Xilinx note on the error, which notes that this error was erroneously thrown in EDK versions <8 : http://www.xilinx.com/support/answers/23645.htm My system is fairly standard. I used BSB and added a few things (LEDs,switches), but nothing particularly exotic. Is there something obvious that I might have missed, or is this likely to be an error with DRC? Thanks AndrewArticle: 137098
>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. You don't have to make it "the" processor. You can tweak the instruction set for each application. That's probably not worth the effort, but it might be critical for some application. (I'm assuming you are writing small chunks of code rather than large things like operating systems or compilers.) A couple of ideas to add to your bag of tricks... You can get constants from a ROM. So a load-immediate of a big number (16 bits) doesn't take 3 bytes of instruction. It's one byte of instruction and a couple of bytes in another ROM. That assumes you have enough bits in the instruction to do a table lookup. In the old days, instruction sets like this were implemented with microcode. One hack that gives you a lot of flexibility is to do a dispatch on the op-code. That lets you use fractional-bits for various fields. Say you have 3 opcodes that all want 10 different values for immediate/constants. You don't have to round up to 16 values, That would take 4x16 slots. Instead, you can do a table lookup (ROM again) on the op-code and pack them into 30 slots. That may cost you a pipeline cycle. ROMs are handy for opcode decoding. Take your 8 or 9 bits (or part of them) and feed that into a wide ROM that gives you all the decoded control signals you need. This is sliding toward the microcode way of thinking. I still think the most important thing you should do is write lots of code so you have some samples to feed to the tools and get some real numbers. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 137099
>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. My guess is that you want a family of load-byte instructions and then a sign-extend instruction, or maybe two if you have 8 vs 9 bit problems. -- These are my opinions, not necessarily my employer's. I hate spam.
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