From 33e4239bcad72a5d6e0b2117bc6cb843f759d125 Mon Sep 17 00:00:00 2001
From: Fischer Moseley <42497969+fischermoseley@users.noreply.github.com>
Date: Thu, 9 Feb 2023 23:09:33 -0500
Subject: [PATCH] Updated Configuring a Core (markdown)

---
 Configuring-a-Core.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Configuring-a-Core.md b/Configuring-a-Core.md
index b10129b..35d8c95 100644
--- a/Configuring-a-Core.md
+++ b/Configuring-a-Core.md
@@ -9,6 +9,7 @@
 # Upload:
 
 # Roadmap / Ongoing Questions:
+* _Packaging_: Manta should fundamentally be out of the way of the hardware developer, so it needs to live on the system, not as source code in the project repo. We learned this with `lab-bc` last semester - we couldn't update it easily and it ended up living in people's git repos. Which shouldn't be necessary since they're not responsible for versioning it - we are. Same mentality here.
 * _Configurable Trigger Location:_ Instead of always centering the downlink core's waveform around where the trigger condition is met, you might want to grab everything before or after the trigger. Or even things that are some number of clock cycles ahead or behind of the trigger. Being able to specify this 'holdoff' or 'position' in the downlink core configuration would be nice. Especially if it's something as simple as `beginning`, `middle`, `end`, or just a number of clock cycles.
 * _Configurable Clock Edge:_ Right now when we add a waveform to a VCD file, we assume that all the values change on the rising edge of the ILA clock. And that's true - we sample them on the rising edge of the input clock. I don't know if we'd want to add an option for clocking in things on the falling edge - I think that's going to make timing hard and students confused.
 * _Reconfigurable uplink cores:_ Instead of loading a BRAM with some fixed content and calling it a day, we should be able to load new data into that memory, and then dump it to the system when needed.