https://community.element14.com/technologies/fpga-group/FPGA discusses the latest trends in programmable logic devices, and offers access to education, workshops, webinars on FPGAs, SoCs, and other programmable devices.en-USTelligent Community 12https://community.element14.com/technologies/fpga-group/w/setup/26642/featured-content-triptych-setup-docWed, 01 Apr 2026 13:35:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:7e3dbc4b-ad3d-4d73-aeac-6597508eadc2JoRatcliffePath to Programmable III Collaborated with Path III is the third session in the element14 Community’s structured FPGA-based SoC training. The first Path was held in 2018 and focused on programmable logic devices PLDs and featured the AVNET MiniZed development board, based on AMD’s Zynq-7000 SoC. Path II convened in 2019 and offered more advanced learning opportunities and featured the AVNET Ultra96-V2 development board, based on AMD’s Zynq UltraScale+ MPSoC. Path III will double the fun by offering structured training on both the MiniZed and Ultra96-V2 boards. Each training track will be followed by a design/build phase. Learn More Adaptive Computing The Bulls Eye® High Performance Test System Samtec Flyover® Technology for FPGA Apps Memory Storage for FPGA Applications Accelerating Embedded Vision with the CrossLink ™ -NX FPGA On Demand Webinars: Getting Started with the AMD Spartan ™ ︎ UltraScale+ ™ ︎ FPGA SCU35 Eval Kit PYNQ-Z2 Workshop Series: FPGA Experiments With Xilinx Pynq-Z2 Power Integrity Effects on FPGA Functionality and Performance Leveling-Up Your FPGA Skills: An Expert Panel Discussion Getting Started with FPGAs: An Expert Panel Discussion Summer of FPGA: Software and FPGA: How to Get the Bits to Flip? Intro to Smart Embedded Vision (SEV) Using a PolarFire ® FPGA Building Processor Based Systems on Lattice FPGAs Using Propelhttps://community.element14.com/technologies/fpga-group/m/managed-videos/151085Mon, 30 Mar 2026 11:29:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:3810f1e8-edff-4437-b7a4-231fdd6b797djc2048https://community.element14.com/technologies/fpga-group/b/blog/posts/lattice-ice40up5k-evb-evaluation-board---part-2-using-the-dsp-multiplierMon, 30 Mar 2026 11:02:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:945974a6-316c-47b3-b406-1c55ba707e6bjc2048Introduction This is a follow-on from this blog and will make more sense if you read that one first. The hardware is exactly the same as in that previous blog, all I'm going to do with this one is adapt (hack might be a better word) the VHDL to perform a different task. Having used the logic elements in the device, I thought it would be interesting to try one of the hard multipliers - the device has eight DSP [digital signal processing] blocks, each of which features a multiplier and an accumulator (a MAC). Since the test code in that previous blog already generates two sine waves, a very easy thing to do would be to simply multiply them together. It's especially convenient in that the multiplier in the DSP block can be used with 16-bit signed values, which happens to be the size of the sines I'm generating with the CORDIC component. I'm going to leave one set to 440Hz and set the other to sixteen times that, plus a little bit (7040.1Hz) so that they move slowly relative to each other. This is the diagram of the DSP block from the family datasheet. It looks very complicated, but isn't really. If you take away the pipeline registers and the muxes, that are there to bypass them if they're not used, what's left is a 16x16 multiplier, made up of four 8-bit multipliers, on the left, and a 32-bit accumulator, made up of a pair of 16-bit accumulators, on the right. That allows the DSP block to work with a single 16 bit multiplier and single 32 bit accumulator, or to be split in two and operate with a pair of 8 bit multipliers, each with a 16-bit accumulator. The VHDL There are basically two ways I can use the multiplier. One is instantiation, the other inference. With instantiation, I create an instance of a DSP component and connect to it as we would for any component in VHDL. That uses a black box component supplied by Lattice that the synthesis and place-and-route know to map to the hard multiplier. That gives a lot of control over the DSP block, but does mean I'll need to read the documentation, and it locks us into the Lattice ecosystem. The 'IP Catalog' includes a multiplier part which is an easier way to set up the instantiation - I haven't tried that yet. With inference, we simply use the multiply operator within VHDL and trust that the synthesis will realise that it can use the hard multiplier within the DSP block and not try and build one out of logic. It almost certainly will do. The advantage of inference is a fair chance of portability (particularly in this case, where other, more expensive, FPGAs designed for serious DSP work generally have multipliers with a longer wordlength). Here's the top level code. It's not actually all that much different: a multiply operator to do the work, some manipulation of the result (which will be 32 bit) to take just the top half in order to reduce it to 16 bits again, and that's it. The other two, for the components, are the same as before. ---------------------------------------------------------------------- -- ***** ice40up5k_evn_test_mult.vhd ***** -- -- -- -- Lattice ICE40UP5K evaluation board multiplier test. -- -- Generates fixed pair of CORDIC 16-bit sine waves, multiplies them-- -- and formats result for an S/PDIF serial optical link. -- -- -- ---------------------------------------------------------------------- -- (C)2026 Jon Clift -- -- Free to use however you want. No warranty as to correctness. -- -- No guarantee of fitness for any purpose. No obligation to support-- ---------------------------------------------------------------------- -- Rev Date Comments -- -- 01 25-Mar-2026 based on ice40up5k_evn_test.vhd -- ---------------------------------------------------------------------- library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; use ieee.math_real.all; entity ice40up5k_evn_test is port( clk_12: in STD_LOGIC; --- system clock in (from 12MHz oscillator) clk_12_288: in STD_LOGIC; --- clock in (from my 12.288MHz oscillator) tp1: out STD_LOGIC; --- scope trigger at start of frame spdif_out: out STD_LOGIC); --- s/pdif data stream (to optical tx) end ice40up5k_evn_test; architecture arch_ice40up5k_evn_test of ice40up5k_evn_test is constant sig_resol: POSITIVE := 16; --- signal resolution (bits) constant pha_resol: POSITIVE := 32; --- phase resolution (bits) signal theta: SIGNED(pha_resol-1 downto 0); --- phase accumulator signal theta_left: SIGNED(pha_resol-1 downto 0); --- left phase accumulator signal theta_right: SIGNED(pha_resol-1 downto 0); --- right phase accumulator signal phase_increment_left: SIGNED(pha_resol-1 downto 0); --- left phase increment signal phase_increment_right: SIGNED(pha_resol-1 downto 0); --- right phase increment signal sine: SIGNED(sig_resol-1 downto 0); --- CORDIC generated sine signal cosine: SIGNED(sig_resol-1 downto 0); --- CORDIC generaated cosine signal sample_left: SIGNED(sig_resol-1 downto 0); --- left sample signal sample_right: SIGNED(sig_resol-1 downto 0); --- right sample signal mult_result: SIGNED(31 downto 0); --- output sample (left * right) signal delay_i: STD_LOGIC; --- signal delay_o: STD_LOGIC; --- signal delay_o_1: STD_LOGIC; --- signal spdif_clk_en: STD_LOGIC; --- signal spdif_sample_en: STD_LOGIC; --- signal sample_en_del1: STD_LOGIC; --- signal sample_en_del2: STD_LOGIC; --- signal prescale_count: UNSIGNED(1 downto 0); --- --- declare the s/pdif output component component spdif_out_component is generic( in_res: POSITIVE); --- audio sample resolution port ( clk_in: in STD_LOGIC; --- clock clk_en: in STD_LOGIC; --- clock enable l_data: in SIGNED(in_res-1 downto 0); --- left audio data in r_data: in SIGNED(in_res-1 downto 0); --- right audio data in next_sample_en: out STD_LOGIC; --- trigger sample update spdif_data_out: out STD_LOGIC); --- output bitstream end component; --- declare the CORDIC component component cordic is generic( input_resol: POSITIVE; --- input resolution output_resol: POSITIVE); --- output resolution port( clk_in: in STD_LOGIC; --- clock in delay_in: in STD_LOGIC; --- delay in delay_out: out STD_LOGIC; --- delay out theta: in SIGNED(pha_resol-1 downto 0); --- phase in sine: out SIGNED(sig_resol-1 downto 0); --- sine out cosine: out SIGNED(sig_resol-1 downto 0)); --- cosine out end component; begin --- main process --- runs two phase accumulators, one for left and one for right --- CORDIC component calculates sine of each --- results stored and handed to spdif component for output formatting evb_test_stuff: process (clk_12_288) is begin if (clk_12_288'event and clk_12_288 = '1') then --- divide clock by 2 to run SPDIF at 6.144MHz for 48ksps if(spdif_clk_en = '0') then spdif_clk_en sig_resol) --- audio sample resolution port map( clk_in => clk_12_288, clk_en => spdif_clk_en, l_data => sample_left, r_data => sample_right, next_sample_en => spdif_sample_en, spdif_data_out => spdif_out); --- instantiate and connect the CORDIC component cordic_1: component cordic generic map( input_resol => pha_resol, --- input resolution output_resol => sig_resol) --- output resolution port map( clk_in => clk_12_288, --- clock in delay_in => delay_i, --- delay in delay_out => delay_o, --- delay out theta => theta, --- phase in sine => sine, --- sine out cosine => cosine); --- cosine out tp1 <= spdif_sample_en; end arch_ice40up5k_evn_test; Results Here's the signal generated. As before, I've passed it through a mixer to clean up the noise. Note that this isn't straight amplitude modulation: the result is double-sideband-suppressed-carrier [the sum and the difference between the two frequencies, without a carrier between them]. For amplitude modulation, the sine envelope would need to be offset so that it was all positive - I might try that later if I get a bit of time. Here's the FFT of that waveform which shows the two sidebands and the absence of a carrier. Quite noisy, though it's difficult to quantify with a fairly basic 8-bit oscilloscope. So the multiplier works fine. The synthesis has definitely used the real multiplier because I can see the use of a single DSP block reported by the place-and-route and see the connections to a DSP block on the physical view. Here's a rather boring video showing the resulting waveform. Unfortunately, I think I have my right and left on the audio swapped - what I'm referring to as 'right' in the code comes out on the white RCA rather than the red one. Ho hum! If you copy this, you'll need to do some simple faultfinding and make a few minor corrections. community.element14.com/.../MVI_5F00_4281.MOV Conclusions Anyway, that's a very simple example of the DSP capabilities of the device in action. The other two elements of this FPGA that I haven't looked at yet are the (single) PLL [usually just used for multiplying-up an input clock] and the block RAM. I'm going to leave the PLL for the moment and in the next blog do something with a block RAM. Further information [1] https://community.element14.com/technologies/fpga-group/b/blog/posts/lattice-ice40up5k-evb-evaluation-board-outputing-audio-sine-waves-over-an-optical-s-pdif-interface [2] https://www.latticesemi.com/en/Products/FPGAandCPLD/iCE40UltraPlus [3] https://www.latticesemi.com/products/developmentboardsandkits/ice40ultraplusbreakoutboard [4] https://uk.farnell.com/lattice-semiconductor/ice40up5k-b-evn/breakout-board-ice40-ultraplus/dp/3770328 [�71.32 + VAT each, Feb 2026] [5] https://en.wikipedia.org/wiki/Double-sideband_suppressed-carrier_transmissionsinefpgacordicvhdldsplatticeice40up5ks/pdifhttps://community.element14.com/technologies/fpga-group/m/managed-videos/151056Fri, 20 Mar 2026 08:19:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:3bd2bf9f-1fb3-4048-9181-b4a3df8a8246jc2048https://community.element14.com/technologies/fpga-group/b/blog/posts/lattice-ice40up5k-evb-evaluation-board-outputing-audio-sine-waves-over-an-optical-s-pdif-interfaceFri, 20 Mar 2026 08:17:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:5106f1ec-c028-4e57-8089-cef080f64d4bjc2048Introduction Quite a long way back, I was fortunate enough to win a shopping basket in a Project 14 competition and the main item I purchased with it was an evaluation board for a Lattice iCE40UP5K FPGA device. Here, finally, is an informal look at that board and the device on it. As part of that, I'll do a small project to demonstrate the board being used. What you get The evaluation board came in a plain cardboard box, wrapped in an antistatic bag which I now seem to have lost. You also get a USB cable and a single, printed sheet that acts as a quick-start guide to finding the design software and other documentation online. The box was folded and taped shut along the top, so, once you've opened it, it no longer functions as a storage box. What you need To use the particular FPGA on this board, with Lattice-supplied development tools, you'll need to install either iCEcube2 or Radiant. iCEcube2 is the legacy tool and Radiant is the more recent (and more capable) tool. I ended up using Radiant running on Xubuntu 22.04 for this review. It is also possible to use open-source tools - there seems to be quite a lot of support for Lattice devices - but, as I don't have any experience of that, I'll stick to the official offering here. Lattice tools are licensed, so you'll need to apply to them for a licence. Generally speaking, the non-SERDES parts (like this one) can use free-of-cost tools, where you are opting out of direct support, though iCEcube2 is now on a subscription for commercial use (still free for hobbyists and start-ups - see their licensing pages for details). The Device The device on the EVB is an iCE40UP5K FPGA. It's a low-cost part adding to a series of devices that originally would have been aimed at simple logic replacement and general interfacing duties. As well as the usual miniscule BGA packages, it's also available as an SG48I package which, although still an SMD part, may be more manageable for a personal project than the fine-pitch BGA parts. The chip is particularly interesting because, with nearly 5k logic blocks, it is a moderately capable device and it has 16-bit hardware multipliers with accumulators [MACs], which would lend themselves to some simple DSP stuff. Obviously this is all relative, and it isn't going to compete head-on with much more capable high-end parts costing hundreds or even thousands of dollars, but the part itself does seem to me to be good value for money and a nice balance of capabilities. Usefully, it also has two hard I2C and two hard SPI interfaces (one of the SPI interfaces is used for configuration). What it won't give you, though, is masses of I/O. The packages are all small, with a limited number of pins. The rest of the board hardware The board is fairly minimalist and, in addition to the FPGA, carries a USB port, an FTDI chip for the device programming, a crystal oscillator (12MHz for the FTDI USB, which can also be routed to the FPGA as a clock), a serial flash memory for the bitstream, and linear regulators for the IO and core power. The board is a reasonable size (3" square), has sensibly-sized mounting holes at each corner, and has unpopulated placements for headers to bring out all the spare I/O. One of the headers is arranged as a PMOD interface, so populating that one would allow access to a wide range of IO boards. Given the price of the board, I thought it a little mean not to populate the headers (my Lattice Brevia 2 board came with the headers installed). The worst thing about what was otherwise a neat and tidy board was that the one I received had the header holes full of solder. Getting solder out of the pin holes that were connected to the ground and power planes, using a hand solder-sucker, was painful. Although I said the part itself was good value, whether the board is will depend on your situation. For a company, it probably represents less than an hour of design engineer time, and is the safe and quick way to evaluate the part if you aren't confident enough to go for an immediate prototype board: you can be reasonably sure it will function with their design tools and programming software. For a personal project, there will be lower cost options out there. Project For a simple project, I'm going to connect an audio fibre-optic transmitter to the board and send out a pair of sine waves calculated with the CORDIC component that I previously developed on an XP2 Brevia board. On the output side, this is basically PCM S/PDIF running over TOSlink. Porting the CORDIC component from XP2 to iCE40UP5K is easy: I just include it as a component in the new code and set the resolution generic appropriately - in this case to 16 bits (CD quality! Approximately. If I'm lucky and get it right). This will require me to develop a simple S/PDIF component for the output side. It's slightly artificial, and a bit limited unless you need a test box with only one, fixed function, but seems a reasonable amount of effort for a review and it could easily be developed further to be more useful. It also takes me a further step on towards doing some electronic music, which can't be a bad thing. The hardware is fairly simple. The optical transmitter part works on 3.3V and can be driven by a single IO pin from the FPGA. Easy-peasy! As with the last couple of XP2 blogs, I'll also need an appropriate clock to derive the audio sample rate, so I've reused the xtal oscillator circuit I used there, with a logic gate for the gain element and a somewhat better choice of components than I used before around the 12.288MHz crystal. Here it is wired on a small prototyping board. The S/PDIF Component S/PDIF is a serial format that was developed jointly by Sony and Philips (hence the S/P part) back in the days of DAT (Digital Audio Tape). It subsequently got used for consumer equipment like CD players. Each frame at the sample rate has two subframes, each carrying a channel of audio at up to 24 bits of resolution, though it's usually used for no more that 20 and, in the case of CD, more normally 16. Along with the audio samples (usually a stereo pair), there's provision for control data and user data sent at a slower rate using single bits within the subframe. The physical interface is either coax (75R with RCA connectors) or plastic optical fibre (with the TOSlink-style transmitter and receiver parts). As a quick aside, S/PDIF derived from a professional transport (AES3) that was developed by broadcasters. AES3 uses different physical interfaces and connectors - either XLR differential pair or BNC 75R coax - more in keeping with a professional studio environment: those two choices allowing use of existing analogue distribution networks for either audio or video. The AES3 spec is open and you can still download it for free from the EBU's website. S/PDIF was adopted by the IEC and so you pay for it, though I'm hoping that there's enough general info around for me to do what I'm doing here without paying thousands of dollars for the priviledge. S/PDIF mostly differs from AES3 in the way the control and user bits are used; the channel coding and the formatting of the audio and the synchronisation are the same as AES3. Because I don't have the actual standard, my implementation will be partial, and I'm going to simply try for enough functionalty to drive a small optical-to-analogue converter box. My main guides here are an old copy of The Art of Digital Audio by Williamson, which appears to cover S/PDIF fairly thoroughly, and the AES3 spec downloaded from the EBU website. If you were actually interested in AES3 itself, it should be straightforward to rework what I've done here for S/PDIF. Because the interface was intended to work with different kinds of equipment there isn't a single, specified sample rate. Originally, it would have been used at 48ksps (DAT), and then 44.1ksps (CD). Commercial chips are likely work to at least 96k/88.4k and maybe even 192k. For what I'm doing here I'm going to work at 48ksps rather than 44.1ksps. Why? Because I have some 12.288MHz crystals (= 256 x 48kHz) that will work nicely to generate the S/PDIF serial bitstream. The VHDL Here's the HDL. ---------------------------------------------------------------------- -- ***** ice40up5k_evn_test.vhd ***** -- -- -- -- Lattice ICE40UP5K evaluation board review test. -- -- Generates fixed pair of CORDIC 16-bit sine waves and formats -- -- them for an S/PDIF serial optical link. -- -- -- ---------------------------------------------------------------------- -- (C)2026 Jon Clift -- -- Free to use however you want. No warranty as to correctness. -- -- No guarantee of fitness for any purpose. No obligation to support-- ---------------------------------------------------------------------- -- Rev Date Comments -- -- 01 23-Feb-2026 -- ---------------------------------------------------------------------- library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; use ieee.math_real.all; entity ice40up5k_evn_test is port( clk_12: in STD_LOGIC; --- system clock in (from 12MHz oscillator) clk_12_288: in STD_LOGIC; --- clock in (from my 12.288MHz oscillator) tp1: out STD_LOGIC; --- scope trigger at start of frame spdif_out: out STD_LOGIC); --- s/pdif data stream (to optical tx) end ice40up5k_evn_test; architecture arch_ice40up5k_evn_test of ice40up5k_evn_test is constant sig_resol: POSITIVE := 16; --- signal resolution (bits) constant pha_resol: POSITIVE := 32; --- phase resolution (bits) signal theta: SIGNED(pha_resol-1 downto 0); --- phase accumulator signal theta_left: SIGNED(pha_resol-1 downto 0); --- left phase accumulator signal theta_right: SIGNED(pha_resol-1 downto 0); --- right phase accumulator signal phase_increment_left: SIGNED(pha_resol-1 downto 0); --- left phase increment signal phase_increment_right: SIGNED(pha_resol-1 downto 0); --- right phase increment signal sine: SIGNED(sig_resol-1 downto 0); --- CORDIC generated sine signal cosine: SIGNED(sig_resol-1 downto 0); --- CORDIC generaated cosine signal sample_left: SIGNED(sig_resol-1 downto 0); --- left sample signal sample_right: SIGNED(sig_resol-1 downto 0); --- right sample signal delay_i: STD_LOGIC; --- signal delay_o: STD_LOGIC; --- signal delay_o_1: STD_LOGIC; --- signal spdif_clk_en: STD_LOGIC; --- signal spdif_sample_en: STD_LOGIC; --- signal sample_en_del1: STD_LOGIC; --- signal sample_en_del2: STD_LOGIC; --- signal prescale_count: UNSIGNED(1 downto 0); --- --- declare the s/pdif output component component spdif_out_component is generic( in_res: POSITIVE); --- audio sample resolution port ( clk_in: in STD_LOGIC; --- clock clk_en: in STD_LOGIC; --- clock enable l_data: in SIGNED(in_res-1 downto 0); --- left audio data in r_data: in SIGNED(in_res-1 downto 0); --- right audio data in next_sample_en: out STD_LOGIC; --- trigger sample update spdif_data_out: out STD_LOGIC); --- output bitstream end component; --- declare the CORDIC component component cordic is generic( input_resol: POSITIVE; --- input resolution output_resol: POSITIVE); --- output resolution port( clk_in: in STD_LOGIC; --- clock in delay_in: in STD_LOGIC; --- delay in delay_out: out STD_LOGIC; --- delay out theta: in SIGNED(pha_resol-1 downto 0); --- phase in sine: out SIGNED(sig_resol-1 downto 0); --- sine out cosine: out SIGNED(sig_resol-1 downto 0)); --- cosine out end component; begin --- main process --- runs two phase accumulators, one for left and one for right --- CORDIC component calculates sine of each --- results stored and handed to spdif component for output formatting evb_test_stuff: process (clk_12_288) is begin if (clk_12_288'event and clk_12_288 = '1') then --- divide clock by 2 to run SPDIF at 6.144MHz for 48ksps if(spdif_clk_en = '0') then spdif_clk_en sig_resol) --- audio sample resolution port map( clk_in => clk_12_288, clk_en => spdif_clk_en, l_data => sample_left, r_data => sample_right, next_sample_en => spdif_sample_en, spdif_data_out => spdif_out); --- instantiate and connect the CORDIC component cordic_1: component cordic generic map( input_resol => pha_resol, --- input resolution output_resol => sig_resol) --- output resolution port map( clk_in => clk_12_288, --- clock in delay_in => delay_i, --- delay in delay_out => delay_o, --- delay out theta => theta, --- phase in sine => sine, --- sine out cosine => cosine); --- cosine out tp1 '0'); begin if (new_size = arg'length) then result := arg; end if; if (new_size arg'length) then result(new_size-1 downto new_size-result'length) := arg(arg'left downto 0); end if; return result; end fractional_resize; -- now for the component code begin temp_phase '0'); wait; end process calc_process; --- now generate the logic for the cordic stages cordic_stages: for k in 0 to output_resol generate begin first_stage: if(k = 0) generate begin first_stage_process: process (clk_in,theta) begin if (clk_in'event and clk_in='1') then del(0) WORD_SIZE) port map(clk_in => clk_in, a => sin_start_value, b => cos_start_value, d => initial_dir, s => sin(0)); addsub_2: component addsub generic map(resol => WORD_SIZE) port map(clk_in => clk_in, a => cos_start_value, b => sin_start_value, d => not_initial_dir, s => cos(0)); addsub_3: component addsub generic map(resol => WORD_SIZE) port map(clk_in => clk_in, a => start_angle, b => angle_coeff(0), d => not_initial_dir, s => angle(0)); end generate first_stage; other_stages: if(k /= 0) generate begin other_stages_process: process (clk_in) begin if (clk_in'event and clk_in='1') then del(k) WORD_SIZE) port map(clk_in => clk_in, a => sin(k-1), b => shift_cos(k), d => dir(k), s => sin(k)); addsub_5: component addsub generic map(resol => WORD_SIZE) port map(clk_in => clk_in, a => cos(k-1), b => shift_sin(k), d => not_dir(k), s => cos(k)); addsub_6: component addsub generic map(resol => WORD_SIZE) port map(clk_in => clk_in, a => angle(k-1), b => angle_coeff(k), d => not_dir(k), s => angle(k)); end generate other_stages; end generate cordic_stages; --- connect outputs to signals in design --- sine and cosine results need resizing (this is crude truncation) --- also need to exclude the additional overhead bit delay_out '0'); begin add_sub_process: process (clk_in) begin if (rising_edge(clk_in)) then if(d = '0') then result '0'); --- set unused audio bits and aux bits to 0 if(subframe_count(0) = '0') then --- load audio sample depending on which subframe, sign bit always aligns with bit 27 shift_reg(27 downto 28-in_res) <= STD_LOGIC_VECTOR(l_data(in_res-1 downto 0)); --- left audio sample goes straight in s/r temp_reg(in_res-1 downto 0) <= STD_LOGIC_VECTOR(r_data(in_res-1 downto 0)); --- right audio sample placed in temp reg next_sample <= '1'; --- trigger generation of next pair of samples else shift_reg(27 downto 28-in_res) <= temp_reg(in_res-1 downto 0); --- move right audio sample from temp to s/r next_sample <= '0'; end if; shift_reg(28) <= '0'; --- validity bit (0 = sample suitable for audio conversion) shift_reg(29) <= '0'; --- user bit (no user data, just fixed at 0) shift_reg(30) <= '0'; --- channel data bit (try with no channel status bits, just forced to 0) --- shift_reg(30 downto 29) <= UC_ARRAY_DATA(to_integer(frame_count(7 downto 0) & half_bit_count(6))); --- user/channel data bits shift_reg(31) <= '0'; --- dummy parity bit - will get overlaid elsif (half_bit_count(0) = '1') then --- otherwise SHIFT on bit boundary... shift_reg(30 downto 0) <= shift_reg(31 downto 1); shift_reg(31) <= '0'; next_sample <= '0'; else --- or hold on the other next_sample <= '0'; end if; --- do differential bi-phase modulation (Manchester encoding) on output of main s/r if(half_bit_count(5 downto 0) = b"111111") then --- start subframe tog_out <= '1'; --- in such a way as to match the end of the preamble elsif(half_bit_count(0) = '1') then --- always toggle on bit boundary tog_out <= not tog_out; else if(shift_reg(0) = '1') then --- toggle on other edge if data 1 tog_out <= not tog_out; end if; end if; --- load or shift the encoded parity --- (final state of bi-phase encoding determines the parity) if (half_bit_count(5 downto 0) = b"111101") then --- load... if(tog_out = '1') then bi_phase_parity(1 downto 0) <= b"00"; else bi_phase_parity(1 downto 0) <= b"10"; end if; else --- shift... bi_phase_parity(1) <= bi_phase_parity(0); bi_phase_parity(0) <= '0'; end if; --- mux to select either preamble, bi-phase data, or parity if(half_bit_count(5 downto 3) = "000") then spdif_data_out <= preamble_shift_reg(7); --- preamble data elsif(half_bit_count(5 downto 1) = "11111") then spdif_data_out <= bi_phase_parity(1); --- encoded parity data else spdif_data_out <= tog_out; --- biphase data end if; end if; --- reduce next_sample_en to a single clock width (not necessarily best place to do this) next_sample_del <= next_sample; if(next_sample = '1' and next_sample_del = '0') then next_sample_en <= '1'; else next_sample_en <= '0'; end if; end if; end process spdif_clocked_stuff; end arch_spdif_out_component; A couple of things about the SPDIF component may not be totally obvious. The standard allows for the preambles to be inverted (in order to deal with a balanced link where the two sides are swapped). That's relevant for a receiver, which must be able to identify either sense, but for my transmitter I can simply choose one or other group. Overall, the frame data is Manchester encoded, except for the preamble. That exception is deliberate in the design of the standard: the preamble breaks the encoding, so that's the way the receiver is sure that it's finding the boundaries and isn't being misled by a pattern occuring in the regular data. That makes the generation of the bitstream a little fiddly. The preamble can't go in the shift register with the frame data - instead I give it its own shift register and have a mux at the end to select between preamble and encoded frame data. Further there's the issue of how to deal with the parity bit. I could have kept track of the parity and inserted it at the approprate time in place of the shift register data, but here I've done it a slightly different way. The effect of the parity bit (with encoding) is to bring the state of the output to the same point at the end of each frame, ready for the same polarity of preamble each time. That means we can use the final state of the encoded data stream, immediately before the parity bit, to determine which one of the two patterns that has to be output to get us to that frame end point (in effect, the Manchester encoding is working out the parity as it goes along for us and we just need to finish off the sequence). So the mux on the end expands to select either preamble, encoded data, or parity. Although I started to implement the additional, slower-rate control and data bitstreams, I thought I'd give it a go without, in the hope the receiver could sort itself out from the bitstream alone. Results It works! (Sort of.) Here is the test output (a pulse marking the start of the frame that gives me something sensible to trigger on), and the SPDIF waveform around that point Here are waveforms from the analogue outputs of the fibre-to-analogue box. Because I've generated two sine waves, one on each channel, that are slightly different frequencies (one is 440.0Hz and the other 440.5Hz), if I trigger an oscilloscope on one, the other will run slowly past it, and the two will align every two seconds [reciprocal of 0.5Hz]. Here's a short video showing that happening. community.element14.com/.../MVI_5F00_4275.MOV So why 'sort of'? The oscilloscope is having a real job trying to trigger on what is supposed to be a very simple, smooth, and precise waveform (a sine wave). Even with the trigger's HF Reject selected, it sometimes triggers on the wrong edge. That's because of all the noise. Here's a close up of what it's doing as it goes through the trigger point. For what is supposed to be 16-bit audio it's pretty bad (that I can see it so obviously on the oscilloscope suggests it's not merely the DAC in the box dithering the lowest few bits). At the moment I've got no idea why, though it's suspiciously digital looking. It might be my CORDIC component, though the only change I made was reducing the resolution to 16 bits; it might be the SPDIF I'm generating - without the control stream the box may be misinterpreting it; it might be the optical link; or it might be to do with the way I'm looking at the signals with the oscilloscope. Plenty of choice there for further investigation. Anyway, be cautious about using any of this in its current form. I'll update the blog when I finally sort it out. I'm coming round to the idea that the noise is coming from the fibre-to-analogue box and there just isn't much attempt, if any, to filter the (mostly out-of-band) noise coming from DAC. [The DAC in the box will be a multi-level delta-sigma running on my samples, but upsampled to move much of the noise about 20kHz.] This is the sinewave as it comes out of that box this is what I see if I pass that signal through a mixer The mixer will have some light, low-pass filtering right at the input, to reduce the effect of RF getting into the signal chain and producing intermodulation products in the active components, and that seems to be enough to dramatically reduce the noise. You can see above that there's still some there, but then the filtering in the mixer won't be tight in to 20kHz, because the designer has to make some assumptions about what's reasonable for the source impedance driving it, and it won't roll-off aggressively either (probably only an RC filter). Perhaps the designer of the box took the view that if you can't hear it, it doesn't matter. It was quite cheap. Conclusions Hopefully, that gives something of a feel for what is possible with the device. The CORDIC component, working 16 bits, and the SPDIF output component take up about two thirds of the part's resources, though the multipliers and the block RAMs are untouched. This was my first time using Radiant and it was fine. It comes across as a rewrite of iCECube 2 with improvements for the various tools and I was able to use it straight away without any need to refer to the help files. The only problem I had was with the in-built programmer in Radiant. It failed on the verify of the serial flash on the board (judging from the messages, it looks like it runs one location past the end of the memory). The evaluation board programs fine using the standalone Diamond programmer, with the same bitstream file, so I worked with that instead of the Radiant one. I haven't tried QuestaSim yet, but it installed ok and can be launched from within Radiant (the two components were simulated with ModelSim: in Diamond for the CORDIC component, and in iCEcube2 for the S/PDIF component). Further information [1] https://www.latticesemi.com/en/Products/FPGAandCPLD/iCE40UltraPlus [2] https://www.latticesemi.com/products/developmentboardsandkits/ice40ultraplusbreakoutboard [3] https://uk.farnell.com/lattice-semiconductor/ice40up5k-b-evn/breakout-board-ice40-ultraplus/dp/3770328 [£71.32 + VAT each, Feb 2026]AES3audiosinewavefpgacordicvhdllatticeice40up5kjc2048s/pdifhttps://community.element14.com/technologies/fpga-group/f/forum/56744/what-is-the-latest-lattice-eval-board/234285Sun, 08 Mar 2026 15:49:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:e706e950-f898-4352-a92a-dbef777c2ecadang74Some of their other newer families have added similar packages. Good move on their part... because BGA imposes a barrier of entry in terms of board cost and assembly.https://community.element14.com/technologies/fpga-group/f/forum/56744/what-is-the-latest-lattice-eval-board/234282Sun, 08 Mar 2026 14:32:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:3d8d245d-69c7-43f0-8468-f7071f7491a0michaelkellettI too would have sworn on my favourite pet's life that the ECP5 was only available in BGA but it seems to also exist in TQFP144: I looked it up on Octopart and Mouser have stock at a reasonable price. The prices from Microchip USA and Worldway are hard to understand. Mouser warn of long delivery times on the website but the 292 in stock seems to be true. MKhttps://community.element14.com/technologies/fpga-group/f/forum/56744/what-is-the-latest-lattice-eval-board/234276Sun, 08 Mar 2026 13:34:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:a6c119f5-0ac3-4199-a139-10dc43aa4433dang74[quote userid="121623" url="~/technologies/fpga-group/f/forum/56744/what-is-the-latest-lattice-eval-board/234274"]Lattice offer hand solderable (just) 48 pin packages for the iCE49UP5k, easier to use and install tools and lower entrance costs[/quote] One Lattice family I am interested in is the ECP5 series. It's what I'd characterize as medium density. At any rate I could have sworn that they were only available in BGA package. I checked again yesterday and the 24,000 and 44,000 LE devices are available in 144 pin TQFP packages... needless to say, I was very happy to see this.https://community.element14.com/technologies/fpga-group/f/forum/56744/what-is-the-latest-lattice-eval-board/234274Sun, 08 Mar 2026 09:46:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:55988fa6-c17c-4f30-9dc4-6743fb827ebcmichaelkellettHello dang74 I did notice it and dismissed it as not being in line with the OP's aims (VHDL.Verilog, learing and interest in soft cores. It is just possible that Cologne Chip will get this architecture off the ground but right now it just doesn't have the support and eco system to make it an attractive proposition for small scale or DIY use. They will need to offer a range of packages and support for industry standard IO (which still definitely includes 3.3V). The only mainstream distribution is via Digi key and the only package is 324 ball 0.8mm BGA (at $21.59 10off). It's just a lot easier to get started with Efinix, Lattice, Altera, Xilinx or Gowin. Lattice offer hand solderable (just) 48 pin packages for the iCE49UP5k, easier to use and install tools and lower entrance costs. The GateMate part is interesting in that it has an architecture quite a bit different from the others but it isn't where I would recommend a beginner to start. MKhttps://community.element14.com/technologies/fpga-group/f/forum/56744/what-is-the-latest-lattice-eval-board/234267Sat, 07 Mar 2026 16:53:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:57f9f52f-fbf5-4682-9678-b9ed3f4df320dang74michaelkellett when you were at the olimex site did you notice the GateMateA1-EVB board. (Full disclaimer, it's not Lattice so it's a bit off topic). Anyway, on the positive side it has 20,480 logic cells and 64Mbit of PSRAM. Of course you have to use open source YOSYS for development so that will be a commitment for some. On my end, I am still wrapping my mind around what exactly PSRAM is and whether or not I can use it as easily SRAM. Perhaps the most disappointing thing for me is that the GPIO tops out at 2.5V... does that mean I've lived long enough to see the phasing out of 3.3V for single ended logic?https://community.element14.com/technologies/fpga-group/f/forum/56744/what-is-the-latest-lattice-eval-board/234266Sat, 07 Mar 2026 15:23:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:bd7b4359-98db-4e72-8dbd-a22a6b467bacvenkat01Nandland's Go Board along with the book is best for beginners.https://community.element14.com/technologies/fpga-group/f/forum/56744/what-is-the-latest-lattice-eval-board/234261Sat, 07 Mar 2026 09:53:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:52b5659c-7f8a-4e51-9f3a-c34eb0424958michaelkellettThe biggest FPGA that Olimex support with a board is on the iCE40HX8K-EVB But this is an early generation ICE40 and not as useful (in most cases ) as the later iCE40UltraPlus parts. Look here for Lattice's suggestions for iCE40 boards: https://www.latticesemi.com/solutionsearch?qiptype=982db688d64345bbb3af29e62fee1dc3&active=board The iCE40 is not very suitable for soft_core work but that has no relevance if you are just starting to learn VHDL or Verilog. (There is some soft core support for soft-cores on the iCE40UP5 but the UP5 is really too small for a decent soft-core) This boards is all you need to get started: https://tinyvision.ai/products/fpga-development-board-upduino-v3-1 There are much cheaper boards based on the Gowin FPGAs available from AliExpress https://www.aliexpress.com/w/wholesale-fpga-dev-board.html They also have pretty cheap Altera or AMD/Xilinx boards as well but you might find that it is hard to get going with the level of support you will get from these. But you will get a much bigger FPGA for your money. IMO the Lattice tools are the easiest for a complete beginner to get started. MKhttps://community.element14.com/technologies/fpga-group/f/forum/56744/what-is-the-latest-lattice-eval-board/234260Sat, 07 Mar 2026 07:56:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:b8627feb-3304-4c03-87eb-578d8db62118dang74Good old Olimex. It's been some time since I checked them out. Thanks for bringing them back on my radar.https://community.element14.com/technologies/fpga-group/f/forum/56744/what-is-the-latest-lattice-eval-board/234259Sat, 07 Mar 2026 04:46:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:30054f35-5ede-4186-8f5a-aed8b3a24daashabazIt may be worth to check out Olimex, they offer a couple of low-cost dev boards for Lattice parts (quite nice, the Olimex boards include SRAM too).https://community.element14.com/technologies/fpga-group/f/forum/56744/what-is-the-latest-lattice-eval-boardFri, 06 Mar 2026 10:41:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:2a129ebf-d1ce-4a93-b275-5038aa19679dJayfoxLooking for a low-cost FPG eval board to start learning Verilog/VHDL and work with soft-core . Lattice seems to be low cost / low power: what is the latest eval board?fpgarisc-vlattice