Generating a desired synthesizable binary pulse train on FPGA using VHDL

On 7/27/2014 8:00 AM, mnentwig wrote:
>
> A genuine ARM, with the hardware multiplier option, would be nice. Those do
> one 32x32=>32 bit multiplication per clock cycle. But, I think an FPGA
> can't do that because I have to cascade two 18x18 multipliers and that
> needs pipeline registers or a slower clock.

I think an ARM CPU would be rather large although they have the M1 (or 
is it the M0?) intended for FPGA use.  I wonder if anyone has cloned 
that yet?

Why would you need it to be cycle accurate?  The multiplier is already 
pipelined even if you just use one by itself.  It comes with an output 
register like the block memory so you can't send the results anywhere 
until the next clock cycle.  Using four of them to produce a 64 bit 
result and save the result in a register would take 2 clocks; one for 
the multiplies and one for the adds and save... unless you do some 
hardware register renaming... set a flag that says the output of the 
multiplier is Rxx instead of the register file.  Hmmmm... I need to 
think about that one.  It takes an extra mux which is not cheap in FPGAs 
though.  The ARM has any number of multi-clock cycle instructions, why 
couldn't the multiply be one of them?

I have this problem in my stack CPU design.  It was originally done in 
an older part where the block RAM can be run async and so a read can be 
written to the top of stack in one clock cycle - *all* instructions are 
1 clock cycle, this is a primary design goal.  With a sync RAM the data 
is not available until the next clock cycle, so I have to find tricks to 
make it work.  One is to use two instructions to read memory, one to 
start the read and one to grab the output - repercussions for 
exceptions, now there is another register to save.  Or I have considered 
grabbing the input to the address register rather than the output and 
doing a read on every clock cycle... somewhat wasteful of power and I 
intend to use this in a low power design.


> So I'll use the softcore for control purposes, and do the "heavy lifting"
> in RTL. Too bad, there is a lot of audio C code out there that could be
> adapted.
>
>> BTW, never use clock speed alone as a measure of performance.  I can't
>> say if the openrisc processor is fast or not.  I find it funny that you
>> would consider using the ZPU if you are looking for speed.  I believe
>> the ZPU is the slowest processor I have ever seen.
>
> Right. The reason is simply that I want to run it synchronously with the
> DSP stuff at around 100 MHz (at least unless someone comes up with a better
> plan). That means, it will limit the maximum clock frequency of the whole
> design.
>
> Even if demoted to front panel controller, the ZPU would still be my choice
> over the 8051 simply because it's 32 bit (got the T-shirt for "8051 front
> panel control" in hand-crafted assembler, a long time ago...)

I wouldn't consider using an 8051 myself if there were good 
alternatives.  But I am in the stack processor crowd (which the ZPU is a 
member of oddly enough) and am happy programming in Forth or something 
like it.  I like working close to the hardware and I find it very useful 
to have a processor with all instructions 1 clock cycle long.  The ZPU 
would drive me batty and I would never want to program it in C.

-- 

Rick

On 7/27/2014 8:00 AM, mnentwig wrote:
>
> Right. The reason is simply that I want to run it synchronously with the
> DSP stuff at around 100 MHz (at least unless someone comes up with a better
> plan). That means, it will limit the maximum clock frequency of the whole
> design.
>
> Even if demoted to front panel controller, the ZPU would still be my choice
> over the 8051 simply because it's 32 bit (got the T-shirt for "8051 front
> panel control" in hand-crafted assembler, a long time ago...)


BTW, do you know about the ZPU mailing list?

zylin-zpu mailing list
zylin-zpu@zylin.com
http://zylin.com/mailman/listinfo/zylin-zpu_zylin.com

-- 

Rick

Yes, thanks. I registered once, maybe I'll have a look through the
archives.
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On 7/29/2014 3:37 PM, mnentwig wrote:
> Yes, thanks. I registered once, maybe I'll have a look through the
> archives.

Perhaps you could start a discussion about what you are doing?  I think 
they have some pretty knowledgeable people there... although one fellow 
tried to tell me that he could add a pipeline register on the negative 
clock edge and it would work as well as one on the positive edge.  I'm 
not sure what he meant.

That reminds me of another way to work around the sync memory problem. 
The memory can be run on the opposite phase of the clock so that it 
writes and reads in the middle of the clock cycle.  The timing specs 
have to be set up for this and it may require some optimization to meet 
timing, but it should work.  :)  I had forgotten all about this.

-- 

Rick

>> sync memory problem.

True... Spartan 6 BRAM manual states
>> The read and write operations are synchronous and require a clock edge

Anyway, I would stay away from anything that's non-standard (at least I
_think_ this is unusual, with the exception of off-chip DDR). 

>Perhaps you could start a discussion about what you are doing?  
There isn't really a lot to discuss on the processor side: A plain ol' CPU,
where FPGA RTL stuff is controlled via registers.
It's some MIDI synthesizer thing, I'm coding up my own '69 Vox Continental
replica, an open-ended holiday/self-study project.
The only performance bottleneck is on key events, when the CPU suddenly
needs to update many virtual key contacts. Ideally I'd like to model switch
bounce in software, but probably I'll do it in RTL and then everything else
can be really slow, thanks to the low MIDI baudrate,

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On Wednesday, 23 July 2014 00:49:52 UTC+8, chaitanya163  wrote:
> Hello Everyone 
> 
>  
> 
> I am new to VHDL programming and FPGA.
> 
> I have a Virtex - 4 FPGA and I wish to generate a  binary pulse train of 16
> 
> pulses from FPGA using VHDL programming. My desired pulse train will be
> 
> like "1011100111101110". (min pulse width should be 30ns).
> 
> I have a clock of 100 MHz and I am able to divide the clock frequency to
> 
> get the clock of 10MHz (clock frequency required for my application). Also
> 
> I am aware of the fact that "Wait for" statement can not be used for
> 
> synthesizing as it can only be used for test bench and simulation purposes.
> 
> 
> 
>  
> 
> So I am struggling with this problem. I am wondering if I can use "after
> 
> Xns" command in my VHDL code or if there is any other way to do it. 
> 
>  
> 
> I will be very thankful if any feedback or advice is provided. Your
> 
> response will truly be appreciated. Kindly provide your valuable
> 
> suggestions. 
> 
>  
> 
> Thanking you
> 
> Regards
> 
> Chaitanya Mauskar
> 
> 
> 
> 	   
> 
> 					
> 
> ---------------------------------------		
> 
> Posted through http://www.FPGARelated.com

I'd write the shift register similar to the following, assuming you have your frequency divider working correctly. Some tools implement this with a 16:1 mux, which is fine.

entity shifter is port(clk,en,reset:in std_ulogic; q:out std_ulogic);
end entity shifter;

architecture rtl of shifter is
    constant s:std_ulogic_vector:=x"1011100111101110";
    signal i:unsigned(3 downto 0); 
begin
    q<=s(to_integer(i));
    
    process(reset,clk) is begin
        if reset then i<=(others=>'0');
        elsif rising_edge(clk) then
            if en then i<=i+1; end if;
        end if; 
    end process;
end architecture rtl;

-dan