Setup repository #2
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A design with VIO probes is inspected (through the GUI of the synthesis tool) when programmed on an FPGA. It therefore makes sense to give each individual probe a logical name. The names of in- and output ports should be given as two `Vec`tor of `Strings`, where the length should match the number of probes. Co-authored-by: Hidde Moll <hidde@qbaylogic.com>
Single-precision floating point addition, realized through instantiation of the Xilinx Floating-Point LogiCORE IP v7.1.
Single-precision floating point operations, realized through instantiation of the Xilinx Floating-Point LogiCORE IP v7.1.
Also don't use `MagicHash` since it's not enabled by default for `clash-testsuite`.
New in `clash-cores`: convert `Unsigned 32` to `Float` with Xilinx IP.
Only a limited number of configurations is supported; see module documentation. The Haskell model does not correspond exactly to RTL. This closes bittide/bittide-hardware#59 Co-authored-by: Martijn Bastiaan <martijn@hmbastiaan.nl> Co-authored-by: Peter Lebbing <peter@digitalbrains.com>
New in `clash-cores`: convert `Signed 32` to `Float` with Xilinx IP.
PR #2345 made it possible to use multiple build targets in all tools. This PR leverages that functionality, combining build targets that were previously split over multiple top entity files. Not counting Vivado, 90% of `clash-testsuite`'s execution time is spent on Clash startup costs. These costs are shared between the multiple build targets, making the test suite a bit quicker.
Co-authored-by: Peter Lebbing <peter@digitalbrains.com>
Before adding the `KEEP` attribute to `vioProbe` ports, clash did not generate valid VHDL since the types of vioProbe declaration and instantiation did not match. This has been fixed, but to make sure these bugs do not occur again the circuits in `shouldwork` are now loaded in Vivado. The circuits in `shouldwork` also did not produce valid VHDL, as the words `in` and `out` are reserved. The names of ports have been updated to produce valid VHDL.
A design with VIO probes is inspected (through the GUI of the synthesis tool) when programmed on an FPGA. It therefore makes sense to give each individual probe a logical name. The names of in- and output ports should be given as two `Vec`tor of `Strings`, where the length should match the number of probes. Co-authored-by: Hidde Moll <hidde@qbaylogic.com>
Co-authored-by: Peter Lebbing <peter@digitalbrains.com>
* The HDL generated incorrectly set DEST_EXT_HSK=0, configuring it to generate acks automatically. While the exposed API and simulation model assumed external handshaking. * The dstStages and srcStages settings were flipped. This also updates the test so it can detect that first error. And improves the haddock a bit to clarify what the settings do and relate them to the XPM documentation.
XpmCdcSingle was using as iots test signal: fromList [0..] :: Signal dom (Unsigned 1) which evaluates to 0 :> 1 :> errorX "finite list". When that flows though sample . fmap pack . unsafeSynchronizer it turns into [0b0, 0b1, 0b., 0b., 0b., ... Now we use the random package to generate random test data. And the seed is also randomly generated via TH on each compile. So everytime you recompile you get different test data.
They raise a warning in GHC 9.2+
In very specific tests in GitLab CI we are affected by GHC bug #19421. We can work around the issue by passing `-with-rtsopts=-xm20000000` when compiling an affected binary. This is a stopgap measure until the real bug is fixed. We have seen the bug: - In `clash-testsuite` in `clashLibTest`s - In `ffi:example` in the `clash` binary itself - In `prelude:doctests`, probably in the `doctests` binary itself, although this is not certain. and then only in GHC 9.0.2, although the bug should be in other versions of GHC as well. This workaround was applied only to GHC 9.0.2 on CI and only to those cases that were observed to go wrong, although as a consequence now the `clash` binary is always built with the RTS option. The `ffi:example` test should no longer be affected by the GHC bug, but it is a fairly useless test in its current state as it does not fail when there are issues, and the tested code is actually faulty. It is disabled to be fixed later.
Co-authored-by: Peter Lebbing <peter@digitalbrains.com>
Makes it available in blackbox implementations
In PRs #2444 we added the workaround-ghc-mmap-crash flag on some of our packages. That flag added `-with-rtsopts=-xm20000000` to some of our binaries. But other binaries would occasionally still trigger the mmap bug, most importantly ghc itself. This commit undoes the previous way of applying the workaround and applies the same `-xm20000000` RTS option everywhere via the GHCRTS environment variable. But for this to work we have to link all binaries with the `-rtsopts` flag, otherwise they'll error out that the GHCRTS contains unsupported options.
This reverts commit 9914030120e3f4bd1631254b020446a076480b24.
So it'll be easier to keep the temp directory
Because of mistakes escaping special characters, some documentation showed the operators `$` and `*` where the Functor and Applicative operators were intended. Since they are all very common operators, this can be very confusing to the reader. Additionally, it was discovered that later versions of Haddock start interpreting Markdown-style links in code blocks, breaking the rendering of the primitive blackboxes in `Clash.Tutorial`. This problem does not occur with GHC 9.0.2 (Haddock 2.25.1), which we use to build the documentation for Hackage. But it does occur with at least GHC 9.6. To make such things less problematic, we decided to use bird tracks (lines starting with '> ') for code blocks that are not Haskell code, and only use the '@...@' style of code block for Haskell code. Bird tracks don't use any formatting at all. All code blocks with something other than Haskell code have been converted to bird tracks. Additionally, some escaping issues in Haskell code blocks were fixed when they were noticed.
For downstream projects needing a newer version
martijnbastiaan
approved these changes
Aug 24, 2024
There was a problem hiding this comment.
100% impossible to review, so here's my blessing :-)
Edit: Could you include the commands you used to migrate over? For an example, see "Repeat this PR" in bittide/bittide-hardware#595.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Now includes the relevant
clash-testsuitetests as well. Old pull request got deleted for some reason..