I want to transfer 8 bits serially (1 bit/clock cycle) through a 1 bit serial interface of a UART. I created an 8 bit packet in the transaction class and drove the packet through the driver modport of the interface. Here is the code snippet below.
for (i = ($size(pkt.RXD)-1); i <= 0; i = i-1) begin
RXSD_vif.DRV.cb_RXSD_DRV.RXD <= RXSD_pkt[i];
end
RXSD_vif is the virtual interface handle.
DRV - modport
cb_RXSD_DRV is the clocking block where I'm taking the positive clock edge with RXD made out to be output.
I'm getting a compile error saying "Too many indices going into RXSD_pkt".
I'm fairly new to this and would appreciate any help in telling me how to fix this. Thanks in advance
I think you're passing the index 'i' to the handle of the packet class. There should be an 8 bit vector within the class through which you need to index. Does this help in any way?
Related
I am currently developing an AES encryption core for a Pynq-Z1 FPGA board. I would like to see the routing of the logic in FPGA logic and timing summary of the design.
The project synthesises, but it results in a warning saying that I am using exceeding the number of IOB blocks on the package. This is understandable because the core takes in and outputs a 4 x 4 matrix.
Instead, I would like to have "internal I/O" in order to see the routing on FPGA fabric. How would I go about doing this? Currently, the device view shows an empty topology (shown below) but my synthesised design utilises 4148 LUT and 389 FF. I expect to see some CLBs highlighted.
design device view
I appreciate any feedback and reference to any application notes which might further progress my FPGA understanding.
Cheers
You can use a simple wrapper around your core with a serial interface. Something like:
entity wrapper is
port(clk, rst, dsi, dsi_core, shift_out: in std_ulogic;
di: in std_ulogic_vector(7 downto 0);
dso_core: out std_ulogic;
do: out std_ulogic_vector(7 downto 0)
);
end entity wrapper;
architecture rtl of wrapper is
signal di_core, do_core, do_buffer: std_ulogic_vector(127 downto 0);
begin
u0: entity work.core(rtl)
port map(clk, rst, dsi_core, di_core, dso_core, do_core);
input_process: process(clk)
begin
if rising_edge(clk) then
if rst = '1' then
di_core <= (others => '0');
elsif dsi = '1' then
di_core <= di & di_core(127 downto 8);
end if;
end if;
end process input_process;
output_process: process(clk)
begin
if rising_edge(clk) then
if rst = '1' then
do_buffer <= (others => '0');
elsif dso_core = '1' then
do_buffer <= do_core;
elsif shift_out = '1' then
do_buffer <= do_buffer(119 downto 0) & X"00";
end if;
end if;
end process output_process;
do <= do_buffer(127 downto 120);
end architecture rtl;
The wrapper just receives inputs, one byte at a time (when dsi = '1') and shifts them in a 128-bits register that is connected to the 128-bits input of your core. When 16 bytes have been entered the environment asserts dsi_core to instruct the core that the 128-bits input can be sampled and processed. The environment waits until the core asserts dso_core, signalling that the processing is over and the 128-bits output is available on the do_core output port of core. When dso_core is asserted the wrapper samples do_core in a 128-bits register (do_buffer). The environment can now read the leftmost byte of do_buffer which drives the do output port of the wrapper. The environment asserts shift_out to shift do_buffer one byte to the left and read the next byte...
This kind of wrapper is a very common practice when you want to test in the real hardware a sub-component of a larger system. As it frequently happens that the number of IOs of sub-components exceeds the number of available IOs, serial input-output solves this. Of course there is a significant latency overhead due to the IO operations but it is just for testing, isn't it?
Your demands are contradictory.
If the design can not place all the I/Os it can not show all the routing as it has not all the begin and/or endpoints. You should reduce your I/O.
The simplest way is to have a real or imaginary interface which much less pins.
An imaginary interface is one which is syntactically correct, reduces your I/Os but will never be used in real life so does not have to be functionally correct.
As it happens you are the third person to ask about reducing I/O in the last weeks and I posted an (untested) SPI interface which has a parameter to generate an arbitrary number of internal inputs and outputs. You can find it here: How can I assign a 256-bit std_logic_vector input
If I have both alwas_comb and always_ff in a single module, which one executed first?.
for example, I have seen this code in a book but I am confused about the functionality. for example, if WE=0 what will be the value of Qout?
module SyncRAM #(parameter M = 4, N = 8)(output logic [N-1:0] Qout,
input logic [M-1:0] Address, input logic [N-1:0] Data, input logic clk, WE);
logic [N-1:0] mem [0:(1<<M)-1];
always_comb
Qout = mem[Address];
always_ff #(posedge clk)
if (~WE)
mem[Address] <= Data;
endmodule
Any help about the truth table of this code is appreciated,
regards
The specific answer to your question is that Qout will just track the value of mem[Address]. In other words, on the rising edge of the clock, if WE is 0, Qout will be driven with the value written to the memory. This is because the memory will behave like a bank of flip-flops, while the Qout output will behave as if it is directly connected to the Q output of a bank of flip-flops.
The order of the execution of the two always blocks is deterministic, because Qout is driven using a blocking assignment (=), whereas the memory is written to using a non-blocking assignment (<=). See the answer here for much more detail.
I am attempting to communicate from my Simblee Rfduino to Matlab, with the following Arduino code:
char testing[] = {1,2,3,4,5,6,7,8,'\0'};
void setup() {
// put your setup code here, to run once:
Serial.begin(9600);
pinMode(6,OUTPUT);
}
void loop() {
// put your main code here, to run repeatedly:
digitalWrite(6,LOW);
Serial.flush();
testing(EMG);
Serial.flush();
digitalWrite(6,HIGH);
}
In Python I am able to correctly read in the 1-8 in the correct order consistently.
However in Matlab it continuously changes order with no consistency, with the following code:
function serial()
global ser
ser = serial('COM5', 'BaudRate', 9600, 'FlowControl', 'hardware');
fopen(ser);
end
function serial_callback(~, ~)
global ser
time = tic;
fread(ser,1) % pull in data from serial port
toc(time);
end
I think there could be some issue in the Serial buffer.
Could you please provide some guidance as to how to consistently get Matlab to read in the data in order? Have others been able to get Matlab to reliably read from a serial port?
Thank you!
You could set the FlowControl to software (xOn and xOff flags). Hardware is only possible if you have the "hardware ressources".
The input buffer of matlab usually works with fifo principle.
After fopen() you have to wait for one second. Because some microcontrollers (like arduino uno ...) restarts after initialization of the uart interface.
--> pause(1);
Hi I am a newborn person to this AVR coding world .
I am developing a 4*4 keypad to take user inputs and to display some of the things in the 16*2 LCD display.
So please u guys as experts I request your suggestions and explanations of such these points.
I kindly request your help on,
I can't understand the following code parts,
#define D5 eS_PORTD5 -
DDRD = 0xFF;
DDRB = 0x0F;
is this code fragment is used a predefined function , if so what is that,
if(bit_is_set (PINB,6))
the full code of this is attached herewith.
thank you for your kindness to waste your time on reading this , please help for a beginner if you know evenone of these things.
DDRD = 0xFF sets all bits of register DDRB to 1 which is setting the port D as outputs
(1 = output, 0 = input)
DDRB = 0x0F is setting portb low 4 bits as output, upper 4 bits as outputs.
bit_is_set a #define from sfr_defs.h, in this case, it checks if bit 6 is set from the PINB port.
it is the equivalent of (PINB & (1<<6))
How does Matlab determine the value of the BytesAvailable which is used in the tmtool for serial connection?
I have to send, say 512 bytes from my Matlab to my device over UART. The problem is only 96 bytes are sent to my device. i don't understand what happened to my remaining bytes! FYI: The value of BytesAvailableFcnCount being shown now is 48. On checking here, I found that the default value is 48. So I increased it to 512; but the same issue recurred. I have BytesAvailable being shown still 95!
Please suggest me some way. I have pasted the code in which I am trying to do this:
fopen(obj1); //obj1 is the name of my serial object
A = fopen('Path of the file I am using');
txdata = fread(A,[5 100],'uint8','ieee-be');
[my_count_rows, my_count_columns]=size(txdata);
for my_i = 1:my_count_columns
for jjj = 1:my_count_rows
fwrite(obj1,txdata(jjj,my_i),'uint8');
end
end