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 137075

Article: 137075
Subject: Re: Bit width in CPU cores
From: rickman <gnuarm@gmail.com>
Date: Sun, 21 Dec 2008 22:36:05 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

Rick

Article: 137076
Subject: Re: Bit width in CPU cores
From: Elizabeth D Rather <erather@forth.com>
Date: Sun, 21 Dec 2008 21:24:51 -1000
Links: << >>  << T >>  << A >>
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
Subject: Re: Bit width in CPU cores
From: Jeremy Bennett <jeremy.bennett@embecosm.com>
Date: Mon, 22 Dec 2008 03:20:14 -0600
Links: << >>  << T >>  << A >>
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: 137078
Subject: Synthesis Problem
From: Digi Suji <digisuji@gmail.com>
Date: Mon, 22 Dec 2008 01:40:43 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

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.

Thanks

Article: 137079
Subject: Re: Why MyHDL?
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Mon, 22 Dec 2008 11:22:11 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: Synthesis Problem
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Mon, 22 Dec 2008 10:24:06 +0000
Links: << >>  << T >>  << A >>
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: 137081
Subject: Need help with the I/O Standard
From: "kashif" <comzian@hotmail.com>
Date: Mon, 22 Dec 2008 07:37:13 -0600
Links: << >>  << T >>  << A >>
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.



Article: 137082
Subject: Re: Need help with the I/O Standard
From: valwn@silvtrc.org
Date: Mon, 22 Dec 2008 14:07:20 +0000 (UTC)
Links: << >>  << T >>  << A >>
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
Subject: Re: Bit width in CPU cores
From: rickman <gnuarm@gmail.com>
Date: Mon, 22 Dec 2008 08:06:13 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

Rick

Article: 137084
Subject: Re: FPGA for Contoll
From: rickman <gnuarm@gmail.com>
Date: Mon, 22 Dec 2008 08:15:48 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

Rick

Article: 137085
Subject: Need comment on the following Verilog always block
From: cpandya@yahoo.com
Date: Mon, 22 Dec 2008 09:31:39 -0800 (PST)
Links: << >>  << T >>  << A >>
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: 137086
Subject: Re: Need comment on the following Verilog always block
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Mon, 22 Dec 2008 17:49:41 +0000
Links: << >>  << T >>  << A >>
On 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
Subject: Re: Synthesis Problem
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Mon, 22 Dec 2008 17:53:34 +0000
Links: << >>  << T >>  << A >>
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
Subject: Re: Bit width in CPU cores
From: m_l_g3 <m_l_g3@yahoo.com>
Date: Mon, 22 Dec 2008 13:16:43 -0800 (PST)
Links: << >>  << T >>  << A >>
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
Subject: Re: Bit width in CPU cores
From: m_l_g3 <m_l_g3@yahoo.com>
Date: Mon, 22 Dec 2008 13:29:04 -0800 (PST)
Links: << >>  << T >>  << A >>
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
Subject: Re: Bit width in CPU cores
From: rickman <gnuarm@gmail.com>
Date: Mon, 22 Dec 2008 14:02:34 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

Rick

Article: 137091
Subject: Adding userports to a custom peripheral in XPS
From: Jan <1@2.3>
Date: Mon, 22 Dec 2008 23:07:05 +0100
Links: << >>  << T >>  << A >>
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
   Jan

Article: 137092
Subject: Re: Synthesis Problem
From: Digi Suji <digisuji@gmail.com>
Date: Mon, 22 Dec 2008 15:41:44 -0800 (PST)
Links: << >>  << T >>  << A >>
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 Chakra

Article: 137093
Subject: Re: Bit width in CPU cores
From: Coos Haak <chforth@hccnet.nl>
Date: Tue, 23 Dec 2008 01:16:19 +0100
Links: << >>  << T >>  << A >>
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.html


Article: 137094
Subject: Re: Bit width in CPU cores
From: Arnim <clv.5.minral@spamgourmet.com>
Date: Tue, 23 Dec 2008 02:03:02 +0100
Links: << >>  << T >>  << A >>

> 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.

Arnim

Article: 137095
Subject: Re: Adding userports to a custom peripheral in XPS
From: "jeremywwebb@gmail.com" <jeremywwebb@gmail.com>
Date: Mon, 22 Dec 2008 20:08:53 -0800 (PST)
Links: << >>  << T >>  << A >>
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,

Jeremy

Article: 137096
Subject: Re: Bit width in CPU cores
From: rickman <gnuarm@gmail.com>
Date: Mon, 22 Dec 2008 22:14:50 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

Rick

Article: 137097
Subject: EDK map error 1492 - incompatible programming error
From: "Andrew W. Hill" <aquaregia27@gmail.com>
Date: Mon, 22 Dec 2008 22:50:36 -0800 (PST)
Links: << >>  << T >>  << A >>
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
Andrew

Article: 137098
Subject: Re: Bit width in CPU cores
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Tue, 23 Dec 2008 03:46:21 -0600
Links: << >>  << T >>  << A >>

>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
Subject: Re: Bit width in CPU cores
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Tue, 23 Dec 2008 04:21:17 -0600
Links: << >>  << T >>  << A >>
>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:
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