flag26838

Members
  • Content count

    16
  • Joined

  • Last visited

Community Reputation

0 Neutral

About flag26838

  • Rank
    Member

Profile Information

  • Gender Not Telling
  1. Well, personally i'm interested in a FPGA board that connects to my RaspberryPI board - there are already two solutions out there: 1) the first[1] one is using a Lattice FPGA and it comes in two flavous - PIF_Z for the RaspberryPI Zero with 2k LUTs and PIF_2 for the RaspberryPI2+ with 7k LUTs, but no external memory 2) the second[2] is using a Xilinx Spartan6 LX9 and 32MB of SDRAM Personally what i would love to see is a Papilio board for the RaspberryPI (Zero / 2+) with some external SRAM and the ability to reuse the Mega/Wings that you already produce, don't know if that fits with your GadgetBox project, but given how much (and how flexible and widespread) are the Raspberries, i guess i wouldn't be the only one interested in such a expansion. 1: http://www.bugblat.com/products/pif/index.html 2: http://valentfx.com/logi-pi/
  2. Hi there, i was wondering if you were thought about building a Papilio FPGA wing (well, actually in the Rpi world they are called Hat) for the RaspberryPi boards, and in case you will ever do that, put some SRAM on it and make it compatible with all the Papilio Wings already available. Thanks dude, keep up the great work.
  3. As a learning exercise, i'm building my own 8bit cpu (while following another "popular" online tutorial truth be told...) - i wrote the decode block, a simple alu, and a register file, but when plumbing all the pieces together, at first, i noticed that the timing of the alu doesn't behave as i expected. Here is a trimmed down example showing my problem: entity decode is Port ( clk : in STD_LOGIC; en : in STD_LOGIC; input : in STD_LOGIC_VECTOR (7 downto 0); output : out STD_LOGIC_VECTOR (3 downto 0));end decode;architecture Behavioral of decode isbeginprocess(clk)begin if rising_edge(clk) then if (en = '1') then output <= input(3 downto 0); end if; end if;end process;end Behavioral;The decode block is super simple: it takes a byte from memory and chops it down in pieces, the 3-0 bits are the opcode and are passed down to the alu. entity alu is Port ( clk : in STD_LOGIC; en : in STD_LOGIC; opcode : in STD_LOGIC_VECTOR (3 downto 0); output : out STD_LOGIC_VECTOR (3 downto 0));end alu;architecture Behavioral of alu isbeginprocess(clk)begin if rising_edge(clk) then if (en = '1') then case opcode(3 downto 0) is when "0001" => output <= "1111"; -- f when others => output <= "1010"; -- a end case; end if; end if;end process;end Behavioral;Again anothe self explanatory module. And here's the testbench: ENTITY testbench ISEND testbench; ARCHITECTURE behavior OF testbench IS -- Component Declaration for the Unit Under Test (UUT) COMPONENT decode PORT( clk : IN std_logic; en : IN std_logic; input : IN std_logic_vector(7 downto 0); output : OUT std_logic_vector(3 downto 0) ); END COMPONENT; COMPONENT alu PORT( clk : IN std_logic; en : IN std_logic; opcode : IN std_logic_vector(3 downto 0); output : OUT std_logic_vector(3 downto 0) ); END COMPONENT; --Inputs signal clk : std_logic := '0'; signal en : std_logic := '0'; signal input : std_logic_vector(7 downto 0) := (others => '0'); signal internal_bus : std_logic_vector(3 downto 0); signal output : std_logic_vector(3 downto 0); -- Clock period definitions constant clk_period : time := 10 ns; BEGIN -- Instantiate the Unit Under Test (UUT) uut: decode PORT MAP ( clk => clk, en => en, input => input, output => internal_bus ); Inst_alu: alu PORT MAP( clk => clk, en => en, opcode => internal_bus, output => output ); -- Clock process definitions clk_process :process begin clk <= '0'; wait for clk_period/2; clk <= '1'; wait for clk_period/2; end process; -- Stimulus process stim_proc: process begin -- hold reset state for 100 ns. wait for 100 ns; en <= '1'; input <= "00000001"; wait; end process;END;And attached is the timing simulation. -after 100ns the simulation starts, and the decode's block input goes to "00000001" -at the first clk rising edge (105ns) the decode block reads the input, chops it down, and passes the opcode "0001" to the alu via the internal_bus signal -at the same rising_edge (105ns), the alu output the default value "1010", instead of "1111" And here's my reasoning and my doubts: Since all the blocks work in parallel, at the first rising edge, if the alu gets the "0001" (as it does looking at the timing simulation), it should output "1111" instead of the catch-all "1010" value. After a second thought, yes all the blocks work in parallel, but there might be a slight delay, and as such, the alu doesn't get the correct value exactly at 105ns, it might get it at 105ns+x, and by then it has processed it's input already. After a third thought, i realized that i was fouled by the timing diagrams in the simulation since at 105ns the input value for the alu isn't stable (indeed there's that crossing of lines to indicate the passage from an undefined to a fixed value), and it can't rely on its input, and as such it has latches put in place to avoid working on an unstable input signal. My guess is that the third is probably the correct hypothesis but i would like to hear from you. In the end, what really puzzles me, is that this behaviour introduce a buffer-like mechanism, and there's no way to avoid it (and probably it's good that you can't avoid it, i don't know...), so the more blocks i add to my cpu, the longer it takes to break down-execute-write-back an instruction. I know, that's how a pipeline is supposed to behave, but at first, coming from a software world, it's not immediately obvious...
  4. Alvieboy, indeed, switching from 'signal' to 'shared variable' made it behave as i expected - any drawback of using a 'shared variable' vs a 'signal'? Thanks for all the answer guys.
  5. I don't understand why this register file: entity reg16_8 is Port ( I_clk : in STD_LOGIC; I_en : in STD_LOGIC; I_we : in STD_LOGIC; I_selA : in STD_LOGIC_VECTOR (2 downto 0); I_selB : in STD_LOGIC_VECTOR (2 downto 0); I_selD : in STD_LOGIC_VECTOR (2 downto 0); I_dataD : in STD_LOGIC_VECTOR (15 downto 0); O_dataA : out STD_LOGIC_VECTOR (15 downto 0); O_dataB : out STD_LOGIC_VECTOR (15 downto 0)); end reg16_8; architecture Behavioral of reg16_8 is type store_t is array(0 to 7) of std_logic_vector(15 downto 0); signal regs: store_t := (others => X"0000"); begin process(I_clk) begin if rising_edge(I_clk) then if I_en='1' then if I_we='1' then regs(to_integer(unsigned(I_selD))) <= I_dataD; end if; O_dataA <= regs(to_integer(unsigned(I_selA))); O_dataB <= regs(to_integer(unsigned(I_selB))); end if; end if; end process; end Behavioral; if run against this test bench: ... -- Stimulus process stim_proc: process begin -- hold reset state for 100 ns. wait for 100 ns; wait for I_clk_period*10; -- insert stimulus here I_selA <= "000"; I_selB <= "001"; I_selD <= "000"; I_dataD <= X"BEEF"; I_we <= '1'; I_en <= '1'; wait for I_clk_period*10; wait; end process; ... takes two clock cycles to update the O_dataA bus - IOW, after 200ns my test bench starts, all input signals are set and i expect at the first rising edge of the clock (205ns), the ouput of the register file to be update, in particular i expect O_dataA to take the value of I_dataD, but that doesn't happen until another clock cycle passes (215ns), when my process() in the register file is executed again. Aren't the staments inside a process executed sequentially? So if i set a register as the first thing in a process(), i expect later statements to pick up this change, am i right? I guess no, since that's not what is happening...
  6. Hi forum, still on my quest to learn VHDL and FPGA, i finally manged to build my own rs232 controller, but now i've some miscellaneous questions about VHDL and the Xilinx ISE: 1) isn't there a way to reuse a previously built chip wihout phisically copying the src code? (e.g. Project -> Add copy of source) In software development you can link your objects against the objs in another directory, fundamentally reusing previously written code, what's the equivalent with the xilinx ise? is that possible at all? I really want to avoid fragmentation. 2) generics are really useful, but i really hate the idea that i need to specify, for example, an interger value and the number of bits necessary to represent it: entiry mod_m_counter is generic( M: integer := 10; -- mod-M N: integer := 4 -- # bits to represent M); and in the upper level chip using this: generic ( DVSR: integer := 104; DVSR_BIT: integer := 7 ); ... baud_generator: mod_m_counter GENERIC MAP( M => DVSR, N => DVSR_BIT) isn't there a way to automatically calculate N in the mod_m_counter? 3) while building the tx part of an rs232 controller, i got this warning: WARNING:PhysDesignRules:781 - PULLUP on an active net. PULLUP of comp tx_PULLUP is set but the tri state is not configured. what does that mean? ...NET TX LOC="P105" | IOSTANDARD=LVTTL | DRIVE=8 | SLEW=FAST | PULLUP; # TX... on a papilio pro + logicstart megawing - besides, the tx part works.
  7. dude, you were right - that example swaps the RX and TX pins around, and using RX instead of TX made my example work, for every keypress different leds light up - cool!
  8. forum, i can't make this example work: http://gadgetfactory.net/learn/2013/12/02/the-quickest-way-to-implement-pc-to-fpga-communication-using-a-papilio-fpga-board/ according to the author i should: "Just build the project, download the project to the FPGA, open a terminal program (I recommend “Putty”), connect to the higher number COM port on the Papilio with the following parameters:9600 baudNo parity1 stop bit Then press some keys to light some LEDs." but the only led that i see blinking, is the TX led on the papilio board (every time i press a key on the terminal emulator, the led blinks - confirming that one byte was transmitted on the line), but the 8 leds on the logicstart megawing don't lit up. So, while trying to debug it, i slightly changed the design: http://pastebin.ubuntu.com/10042389/ 1) i connected the data_strobe line to the dp signal of the 7seg and set an initial value of '1' (DP should be off)2) i flipped the tmp signal ( <= '0' - turning on the DP) insided the if-block when the oversampled_bits vector was checked against the starting bit3) i "enhanced" the starting bit check, adding the check for the stop bit too what i expected was for the DP to stay off until i sent the first char, but to my surprise the DP was immediately lit up (even if i didn't open the terminal emulator, so having nothing connected to the ttyUSB line - and i was sure the TX led on the papilio boatd was off all the time).At this point, as another experiment, i changed the check for the stop bit (from "111" to "000"), and again the DP lit up immediately - so, no matter what i checked there, that if-block is always executed. Any idea what i'm doing wrong here or how to debug it?rs232_rx.tar
  9. i was under the impression (perhaps i read it somewhere but i forgot where...) that the switches on the logicstart where hw debounced, am i correct?
  10. anyway, i just wanted to thank everyone, much appreciated
  11. Thanks Jack, but don't waste your time, i was able to squeeze in more bits using the mini jostick and so far i'm good
  12. 1 is doable but is a bit tedious to use 2 is overkill for my learning exercises 3 i'll give it a look i need more inputs to implement the exercises found in the book "FPGA PROTOTYPING BY VHDL EXAMPLES" from Pong Chu - registers, primitive data type (fifo, stack, etc), silly examples using the ssegs, etc - i'm still at chapter 4
  13. Amazing, i didn't know i could hook it that way, i'll give it a shot!
  14. As the subject says, i'm a newbie learning fpga and vhdl programming and i need more than the 8 input switches provided by my logicstart megawing and i was wondering if anyone had already faced this problem and how you solved it. These are some ideas that i had to increase my "input bus" width: 1) first i thought about connecting some switches to the adc connectors, but in that case i would need a working spi decoder first - this one it might end up being a good vhdl coding exercise 2) i can use the mini joystick as another source of inputs (4 positions => 2 input bits) 3) ??? i would love to reach 12 or even 16 bits of input without resorting to soldering or any other permanent mods, do you have any idea how to achieve it?
  15. but i don't undestand why so, i mean, from a process perspective, any signal listed in a process sensitivy list are just vanilla electronic tracks that, at some point in time, change their logical value hence trigger the process body, so why would the "compiler" assume the en signal is a clock (and thus complain when it's not)? does it have to be a clk to used in a process sensitivy list? is it mandatory? some kind of VHDL constraint maybe? what i'm trying to achieve, is to trigger the process body only when i "turn on" a specific switch