On Feb 10, 4:23 pm, jleslie48 <j...@jonathanleslie.com> wrote:
> On Feb 10, 2:44 pm, jleslie48 <j...@jonathanleslie.com> wrote:
>
>
>
> > On Feb 10, 1:17 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
> > wrote:
>
> > > On Tue, 10 Feb 2009 08:33:14 -0800 (PST), jleslie48 wrote:
> > > > I think the next step is
> > > >to update the goto functionality to be a goto LABEL instead of
> > > >a PC location. So I think a good project is to add the
> > > >'OP_LABEL [char]' mnemonic and re-tool the goto to
> > > > walk through the ROM?? looking for the label.
>
> > > Or, maybe, scan the ROM just once at startup, cacheing
> > > the label addresses in a second blockRAM organized as
> > > a table of PC values indexed by character.
>
> > > It will still be a long way from Turing-completeness :-)
> > > and a very long way from doing any useful DSP :-(
> > > --
> > > 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.
>
> > even better ;)
>
> > but being able to scan a rom for specific signals, (label)
> > and caching them you don't consider a worthwhile process of a
> > DSP?
>
> looking at the function contents, what is the purpose of this line:
>
> constant p: t_ubyte_array (0 to pgm'length-1) := pgm;
>
> in this context:
>
> -- Function to convert the generic value into ROM-contents format
> function contents(pgm: t_ubyte_array) return t_rom is
> constant p: t_ubyte_array (0 to pgm'length-1) := pgm;
> variable it: t_rom;
> begin
> it := (others => 0);
> for iloop in p'range loop
> it(iloop) := p(iloop);
> end loop;
> return it;
> end;
>
> It appears to me that constant 'p' is just a copy of pgm, what is
> wrong
> with just:
>
> -- Function to convert the generic value into ROM-contents format
> function contents(pgm: t_ubyte_array) return t_rom is
> -- xxxxxxxxxx
> variable it: t_rom;
> begin
> it := (others => 0);
> for iloop in pgm'range loop
> it(iloop) := pgm(iloop);
> end loop;
> return it;
> end;
>
> I tried it it synth's, implements and generates, but it doesn't run/
> work, but why?
>
> update;
>
> this does work though:
> -- Function to convert the generic value into ROM-contents format
> function contents(pgm: t_ubyte_array) return t_rom is
> --constant p: t_ubyte_array (0 to pgm'length-1) := pgm;
> variable it: t_rom;
> begin
> it := (others => 0);
> for iloop in 0 to pgm'length-1 loop
> it(iloop) := pgm(iloop);
> end loop;
> return it;
> end;
another question, given 'the_program'
-- address....... 0 1 2 3 4 5 6 7 8 9
-- data (char)... 'T' '2' 'M' 'h' 'e' 'l' 'l' 'o' NUL NUL
-- data (byte)... 84 50 77 104 101 109 109 111 0 0
--
I'm not understanding the timing of events here:
-- Look at where our fetch/execute machine has got to.
case gen_state is
when init => -- Just come out of reset. Begin fetching
PC <= 0; -- from address 0.
reset_out <= '1';
gen_state <= do_reset; -- drive reset to other logic
halted <= '0';
tx_valid <= '0';
tx_data <= (others => '0');
delay_counter <= 5; -- reset interval
when do_reset => -- OK to start work now.
if timer = '1' then
if delay_counter = 0 then
reset_out <= '0';
gen_state <= new_PC; -- Give the ROM output time to
settle.
else
delay_counter <= delay_counter - 1;
end if;
end if;
when new_PC => -- PC has just changed. Next we will fetch the
gen_state <= fetch; -- instruction we have addressed....
PC <= PC + 1; -- and then increment PC ready for the next
read.
when fetch => -- The rom_data is now ready for us.
operation <= rom_data; -- Copy it into our operation
register.
gen_state <= decode; -- And move on to do a decode.
----------------------------------------------------------------------------------
after the gen_state finishes the delay_counter countdown,
its switches the gen_state to new_PC and the PC == 0.
on the next rising edge of the clock, the gen_state switches to
'fetch' and the PC increments to '1'
on the next clock pulse, the gen_state is fetch and it tries
to set the operation to the rom_data, specifically, the_rom(1)
which is not an operation at all, but rather the data value of the
operation declared in the_rom(0).
Now I know I got something wrong, because this works, but my
'stepping through' the code implies to me that the PC increment
that is part of the fetch will jump over the operation to the
operations
data.
Reply by jleslie48●February 10, 20092009-02-10
On Feb 10, 2:44 pm, jleslie48 <j...@jonathanleslie.com> wrote:
> On Feb 10, 1:17 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
> wrote:
>
>
>
> > On Tue, 10 Feb 2009 08:33:14 -0800 (PST), jleslie48 wrote:
> > > I think the next step is
> > >to update the goto functionality to be a goto LABEL instead of
> > >a PC location. So I think a good project is to add the
> > >'OP_LABEL [char]' mnemonic and re-tool the goto to
> > > walk through the ROM?? looking for the label.
>
> > Or, maybe, scan the ROM just once at startup, cacheing
> > the label addresses in a second blockRAM organized as
> > a table of PC values indexed by character.
>
> > It will still be a long way from Turing-completeness :-)
> > and a very long way from doing any useful DSP :-(
> > --
> > 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.
>
> even better ;)
>
> but being able to scan a rom for specific signals, (label)
> and caching them you don't consider a worthwhile process of a
> DSP?
looking at the function contents, what is the purpose of this line:
constant p: t_ubyte_array (0 to pgm'length-1) := pgm;
in this context:
-- Function to convert the generic value into ROM-contents format
function contents(pgm: t_ubyte_array) return t_rom is
constant p: t_ubyte_array (0 to pgm'length-1) := pgm;
variable it: t_rom;
begin
it := (others => 0);
for iloop in p'range loop
it(iloop) := p(iloop);
end loop;
return it;
end;
It appears to me that constant 'p' is just a copy of pgm, what is
wrong
with just:
-- Function to convert the generic value into ROM-contents format
function contents(pgm: t_ubyte_array) return t_rom is
-- xxxxxxxxxx
variable it: t_rom;
begin
it := (others => 0);
for iloop in pgm'range loop
it(iloop) := pgm(iloop);
end loop;
return it;
end;
I tried it it synth's, implements and generates, but it doesn't run/
work, but why?
update;
this does work though:
-- Function to convert the generic value into ROM-contents format
function contents(pgm: t_ubyte_array) return t_rom is
--constant p: t_ubyte_array (0 to pgm'length-1) := pgm;
variable it: t_rom;
begin
it := (others => 0);
for iloop in 0 to pgm'length-1 loop
it(iloop) := pgm(iloop);
end loop;
return it;
end;
Reply by jleslie48●February 10, 20092009-02-10
On Feb 10, 1:17 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Tue, 10 Feb 2009 08:33:14 -0800 (PST), jleslie48 wrote:
> > I think the next step is
> >to update the goto functionality to be a goto LABEL instead of
> >a PC location. So I think a good project is to add the
> >'OP_LABEL [char]' mnemonic and re-tool the goto to
> > walk through the ROM?? looking for the label.
>
> Or, maybe, scan the ROM just once at startup, cacheing
> the label addresses in a second blockRAM organized as
> a table of PC values indexed by character.
>
> It will still be a long way from Turing-completeness :-)
> and a very long way from doing any useful DSP :-(
> --
> 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.
even better ;)
but being able to scan a rom for specific signals, (label)
and caching them you don't consider a worthwhile process of a
DSP?
Reply by Jonathan Bromley●February 10, 20092009-02-10
On Tue, 10 Feb 2009 08:33:14 -0800 (PST), jleslie48 wrote:
> I think the next step is
>to update the goto functionality to be a goto LABEL instead of
>a PC location. So I think a good project is to add the
>'OP_LABEL [char]' mnemonic and re-tool the goto to
> walk through the ROM?? looking for the label.
Or, maybe, scan the ROM just once at startup, cacheing
the label addresses in a second blockRAM organized as
a table of PC values indexed by character.
It will still be a long way from Turing-completeness :-)
and a very long way from doing any useful DSP :-(
--
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.